search

openSUSE-Rust / cargo-packaging

Cargo Packaging macros
Mozilla Public License 2.0
5 stars 6 forks source link

Enable printing command lines #2

Closed jengelh closed 2 years ago

jengelh commented 2 years ago

openSUSE is using --disable-silent-rules in many packages; apply the same for cargo, but on a global scale.

jengelh commented 2 years ago

What benefit will this bring to packagers/developers?

Seeing the flags that were used even when the build doesn't fail, especially to confirm (by humans or automated tools) that the expected ones are in it. post-build-checks analyzed command lines that way to ensure conformance with distro policies (it has moved to a smarter method but which is not applicable to rust).

Firstyear commented 2 years ago

What benefit will this bring to packagers/developers?

Seeing the flags that were used even when the build doesn't fail, especially to confirm (by humans or automated tools) that the expected ones are in it. post-build-checks analyzed command lines that way to ensure conformance with distro policies (it has moved to a smarter method but which is not applicable to rust).

Currently there is no post-build check that relies on this anyway for rust. When we do set flags they are in an environment variable that rust reads, and isn't displayed on the CLI. So adding verbosity won't help here for checking "did it do the right thing". You need to check in other ways.

I think the approach here is wrong - this PR is prescribing a solution without framing the problem. When it needs to however frame the problem and examine it in the context of Rust (not C).

brjsp commented 3 months ago

The problem i have noticed is that some packages i maintain (signal-desktop and dependents) do bizarre FFI shenanigans. I need to make sure that the C code is built with the correct optflags, and also need to see the linker commandline. I add --verbose to RUSTFLAGS but that is not even sufficient. To see any sort of useful build output i also have to:

Firstyear commented 3 months ago

In these cases can you not just do %{cargo_build} -v ?

brjsp commented 3 months ago

In these cases can you not just do %{cargo_build} -v ?

I do not use %cargo_build for two reasons:

(Posting this just so posterity will know how much of a mess Rust is from a packager's perspective)

Firstyear commented 3 months ago

In these cases can you not just do %{cargo_build} -v ?

I'm not against this btw, I just think there needs to be a clear "we can't do this with what we already have" use case.

I do not use %cargo_build for two reasons:

* The package must build on both openSUSE and Fedora (This is why i reported [bsc#1212226](https://bugzilla.suse.com/show_bug.cgi?id=1212226) to you previously, thanks for fixing that!)

No problems :) 

* I need to inject some per-package feature flags to rustc to build the correct target. Sometimes it's more reliable to [hack the upstream build script to do what we want](https://build.opensuse.org/projects/network:im:signal/packages/libsignal/files/build_node_bridge-inject-options.patch?expand=1) than to extract the command lines by some other means.

(Posting this just so posterity will know how much of a mess Rust is from a packager's perspective)

The signal issue you posted is because libsignal is wrapping cargo, which means that the indirection there is the problem rather than anything rust does.

cargo auditable strictly speaking isn't required. It's just there for supporting SBOM, so if you're willing to generate the provides statements manually, you can just drop it.

And the other part of this mess is how things are approached in other distros. Fedora especially makes a mess of this, and has a lot of "anti-patterns" which is really difficult to escape from.