Modify the rustc [build] and [rust] sections of config.toml

[ken@…]

Comments 55, 56, 57 in #17501.

Sounds as if this can change how we do the install (although I like having at least one DESTDIR example in the book).

I've had enough of building rust for the moment, anyone who wishes can take this.

A quick search for locked-deps found a lot of links which might not be for rust, I have no understanding of what these changed [build] parameters will do.

[ken@…]

Replying to ken@…:

A quick search for locked-deps found a lot of links which might not be for rust, I have no understanding of what these changed [build] parameters will do.

Pedantically, I can see them in config.toml but I do not speak rustacean and have found that what happens with changed parameters does not always match my assumptions.

[Xi Ruoyao]

Replying to ken@…:

Replying to ken@…:

A quick search for locked-deps found a lot of links which might not be for rust, I have no understanding of what these changed [build] parameters will do.

Pedantically, I can see them in config.toml but I do not speak rustacean and have found that what happens with changed parameters does not always match my assumptions.

locked-deps = true means "use the versions of dependencies specified in shipped Cargo.lock files, instead of attempting to update the versions".

vendor = true means "use the dependencies shipped in the tarball, instead of downloading them".

So vendor = true allows us to avoid downloading the crates on the fly. But if vendor = true and locked-deps = false, the build will fail due to a version mismatch. So I'd like to add both of them as true.

This also avoids the problem that "different BLFS Rustc build may use different dependency versions even though the BLFS book version and Rustc version is not changed", which is destroying the concept of "stable" release.

[Xi Ruoyao]

I'll self-assign the ticket if no objection.

[ken@…]

Replying to Xi Ruoyao:

I'll self-assign the ticket if no objection.

No objection from me.

[pierre]

There was no objection from me either :) Since I've begun reading the rust book, I'll tell what I understand about locked dependencies. When building rust projects with cargo, the project dependencies are specified in the cargo.toml file in the form:

[dependencies]
some_dep = "x.y.z"

where x.y.z is a version. This does not mean "use the x.y.z version", but use that version or any later version that does not break the ABI, according to ​semantic versioning. Basically, if x=0, then ABI may be broken at y+1, so accept only versions x.y.z+n, where n>=0. If x>0, then ABI break will occur at x+1, so accept versions x.(y+n).p, with n>=0 and p>=z if n is zero.

But all that means a build may be different if a later version of a dependency is out. This is the reason why cargo.lock files are created, that record the current versions a project has been built with. Using those cargo.lock files, reproducible builds can be achieved even if later versions of dependencies exist.

In the rust build tree, cargo.lock files are provided, and "locked-deps = true" means: use those versions of the dependencies. Now those versions of the dependencies are bundled into the build tree, so they can be used without downloading them from the ​crate registry.

I've tried to remove my ~/.cargo directory and run the build with the options as proposed by Xi Ruoyao, and at the end, ~/.cargo is created, but empty.

[Xi Ruoyao]

Done at r11.2-815-g97e721913b.