Rust-Written Coreutils Replacement uutils 0.0.19 Released

[NobodyXu]

Thanks a lot for elaborating. I think it is important to "look beyond the fence" even as a non-rust programmer. (or shall I say "not-yet-rust programmer" ?)

You are welcome, rust has a official book for introducing to rust, including the use of rustc and cargo and how to use crates.io

https://doc.rust-lang.org/book/

[lowflyer]

Sorry I have no idea what happened to the forum system.

This is an issue for Michael . I meant to put his name into that line. However, It seems to work again. Pagination apparently solves it. Quoting from page Forum still doesn't work. Some "construction" on page Forum seems to disable it.

Yes, kind of.
Here is an example `Cargo.toml` adapted from ...

Thanks a lot for elaborating. I think it is important to "look beyond the fence" even as a non-rust programmer. (or shall I say "not-yet-rust programmer" ?)

[NobodyXu]

I still can't quote you directly ...

Sorry I have no idea what happened to the forum system.

You mean cargo is something similar like cpm or even conan?

Yes, kind of.
Here is an example `Cargo.toml` adapted from https://github.com/cargo-bins/cargo-...in/Cargo.toml:

[package]
name = "cargo-binstall"
description = "Rust binary package installer for CI integration"
repository = "https://github.com/cargo-bins/cargo-binstall"
version = "0.23.1"
rust-version = "1.65.0"
authors = ["ryan <[email protected]>"]
edition = "2021"
license = "GPL-3.0"

[dependencies]
binstalk = { path = "../binstalk", version = "0.12.1", default-features = false }
binstalk-manifests = { path = "../binstalk-manifests", version = "0.5.0" }
clap = { version = "4.3.0", features = ["derive", "env"] }
compact_str = "0.7.0"
dirs = "5.0.1"
file-format = { version = "0.17.0", default-features = false }
fs-lock = { version = "0.1.0", path = "../fs-lock" }
gh-token = "0.1.2"
log = { version = "0.4.18", features = ["std"] }
miette = "5.9.0"
mimalloc = { version = "0.1.37", default-features = false, optional = true }
once_cell = "1.18.0"
semver = "1.0.17"
strum = "0.24.1"
strum_macros = "0.24.3"
supports-color = "2.0.0"
tempfile = "3.5.0"
tokio = { version = "1.28.2", features = ["rt-multi-thread"], default-features = false }
tracing-core = "0.1.31"
tracing = { version = "0.1.37", default-features = false }
tracing-log = { version = "0.1.3", default-features = false }
tracing-subscriber = { version = "0.3.17", features = ["fmt", "json", "ansi"], default-features = false }

[features]
default = ["static", "rustls", "trust-dns", "fancy-no-backtrace", "zstd-thin"]

mimalloc = ["dep:mimalloc"]

static = ["binstalk/static"]
pkg-config = ["binstalk/pkg-config"]

zlib-ng = ["binstalk/zlib-ng"]

rustls = ["binstalk/rustls"]
native-tls = ["binstalk/native-tls"]

trust-dns = ["binstalk/trust-dns"]

zstd-thin = ["binstalk/zstd-thin"]
cross-lang-fat-lto = ["binstalk/cross-lang-fat-lto"]

fancy-no-backtrace = ["miette/fancy-no-backtrace"]
fancy-with-backtrace = ["fancy-no-backtrace", "miette/fancy"]

log_max_level_info = ["log/max_level_info", "tracing/max_level_info", "log_release_max_level_info"]
log_max_level_debug = ["log/max_level_debug", "tracing/max_level_debug", "log_release_max_level_debug"]

log_release_max_level_info = ["log/release_max_level_info", "tracing/release_max_level_info"]
log_release_max_level_debug = ["log/release_max_level_debug", "tracing/release_max_level_debug"]

[profile.release]
opt-level = "z"
lto = true
codegen-units = 1
panic = "abort"
strip = "symbols"

`package` section provides information about current package, `dependencies` specifies the dependencies.

Some dependencies have both `path` and `version` because they are developed in the same repository, so in the CI, they would use the version found in path.
When installing from crates.io on end-user machine, they will use the `version` pulled from crates.io

You might also notice some dependencies have `features` and `default-features` to control what feature is provided.
In cargo, features are designed to be addictive and all features enabled on the same package will be merged, so the package will built once with all features enabled across all dependencies and current package.

`features` section describes features provided by the current package, it can be used to either enable optional dependencies or features of dependencies, or include more code using the `cfg(features = "...")` conditional compilation, which can also use `all(feature = ..., feature = ...)`, `any(...)` plus `cfg(unix)`, `cfg(windows)`, etc.

Finally, section `profile.release` specifies the compilation flags for release, including optimization level, whether to use lto ("lto = true" enables fat lto, 'lto = "thin"' enables thin lto).

[lowflyer]

I still can't quote you directly ...

In rust, you just need to add one line like 'rand = "0.8"' and then you can proceed to use it in your crate, knowing that cargo will download and build it for you.
You can then clone the repository and build it with cargo on another target, with cargo handling all the dependencies for you.

You mean cargo is something similar like cpm or even conan?

[NobodyXu]

On windows you just install the binaries. A package manager will happily do this for you. If you insist on building it yourself, this is the command:

b2 -j30 --build-type=complete toolset=msvc-19.0 stage

I don't see major differences compared to the hoops and hassles you have to go through with rust.

In rust, you just need to add one line like 'rand = "0.8"' and then you can proceed to use it in your crate, knowing that cargo will download and build it for you.
You can then clone the repository and build it with cargo on another target, with cargo handling all the dependencies for you.

[lowflyer]

Most boost libraries are header-only, but for ones that need to be compiled, you would still need to compile them.
Compared to managing dependencies using package manager like cargo, it is indeed a hassle.

Besides, whether it is a "hassle" depends on expectation, if you expect to manually manage everything and enjoy the process of doing so, then yeah it is not that of a hassle since most of the libraries don't need to be compiled and compiling it not hard, but compared to package manager it is indeed much harder.

On windows you just install the binaries. A package manager will happily do this for you. If you insist on building it yourself, this is the command:

b2 -j30 --build-type=complete toolset=msvc-19.0 stage

I don't see major differences compared to the hoops and hassles you have to go through with rust.

[NobodyXu]

If you try to give away the impression that you know boost, you better not write untruths like this:

Most boost libraries are header-only, but for ones that need to be compiled, you would still need to compile them.
Compared to managing dependencies using package manager like cargo, it is indeed a hassle.

Besides, whether it is a "hassle" depends on expectation, if you expect to manually manage everything and enjoy the process of doing so, then yeah it is not that of a hassle since most of the libraries don't need to be compiled and compiling it not hard, but compared to package manager it is indeed much harder.

[lowflyer]

Yes, I was talking about boost.

If you try to give away the impression that you know boost, you better not write untruths like this:

Installing boost on Windows would still be a hassle,

[NobodyXu]

There are binary crates??? This contradicts your earlier answer to my direct question:

All crates are stored in source form in crates.io

"Binary crates" refer to crates with a src/main.rs or src/bin/*.rs, when running cargo-build it will produce an executable.
"Library crates" refer to crates with a src/lib.rs, running cargo-build will compile and produce an achieve of object files.

I have the impression the more I ask - the more complicated the rust setup gets.

It's probably because we are talking about different things.
Usually we justnuse https://rustup.rs to install rustc (compiler) and cargo (package manager).

cargo, the package manager, is responsible for downloading dependencies based on manifests.
It supports alternative registries which can be used for self-hosting registries in cooperation internal network, where access to internet is blocked.

cargo also supports flag "--offline" if the index and dependencies are already downloaded.

NOT TRUE! I don't know why you say that. Are your sure you talking about the C++ Boost project from https://www.boost.org/ ???

Yes, I was talking about boost.
While most of the boost libraries are header-only, there are still a few that requires building https://www.boost.org/doc/libs/1_82_...only-libraries :

The only Boost libraries that must be built separately are:

• Boost.Chrono
• Boost.Context
• Boost.Filesystem
• Boost.GraphParallel
• Boost.IOStreams
• Boost.Locale
• Boost.Log (see build documentation)
• Boost.MPI
• Boost.ProgramOptions
• Boost.Python (see the Boost.Python build documentation before building and installing it)
• Boost.Regex
• Boost.Serialization
• Boost.Thread
• Boost.Timer
• Boost.Wave

A few libraries have optional separately-compiled binaries:

• Boost.Graph also has a binary component that is only needed if you intend to parse GraphViz files.
• Boost.Math has binary components for the TR1 and C99 cmath functions.
• Boost.Random has a binary component which is only needed if you're using random_device.
• Boost.Test can be used in “header-only” or “separately compiled” mode, although separate compilation is recommended for serious use.
• Boost.Exception provides non-intrusive implementation of exception_ptr for 32-bit _MSC_VER==1310 and _MSC_VER==1400 which requires a separately-compiled binary. This is enabled by #define BOOST_ENABLE_NON_INTRUSIVE_EXCEPTION_PTR.
• Boost.System is header-only since Boost 1.69. A stub library is still built for compatibility, but linking to it is no longer necessary.

[lowflyer]

So for binary crates, we only need to distribute the executables.

There are binary crates??? This contradicts your earlier answer to my direct question:

it stores crates in source form and is immutable.

IMHO the best way is to host your own crates.io registry in your local network.

I have the impression the more I ask - the more complicated the rust setup gets.

Installing boost on Windows would still be a hassle,

NOT TRUE! I don't know why you say that. Are your sure you talking about the C++ Boost project from https://www.boost.org/ ???