Rust-GCC
Check for cargo when building rust language
Is it expected that GCC Rust build and test / build-and-check-gcc-48 failed here: configure: error: Cargo is required to build rust -- per the Install Deps step, Rust/Cargo is being installed? Is this hopefully just some kind of scripting issue?
Per a quick look, these changes look like (the first part of) how I think they should look like, thanks! In case there are requests for changes, I suggest to first get this reviewed on [email protected] and committed upstream, before pushing to GCC/Rust (here).
And then ("the next part") we should add a check that the object files that Cargo produces for a simple (dummy) crate can actually be linked into the GCC compiler we're about to build. This is to detect early cases like described in #2898 "cargo should build for the host system", or #2899 "Pass configuration flags to cargo", and still be able to react (disable Rust language, or sensible error message, as applicable), instead of later running into a build error.
And then ("the next part") we should add a check that the object files that Cargo produces for a simple (dummy) crate can actually be linked into the GCC compiler we're about to build. This is to detect early cases like described in #2898 "
cargoshould build for the host system", or #2899 "Pass configuration flags tocargo", and still be able to react (disable Rust language, or sensible error message, as applicable), instead of later running into a build error.
In fact, I've been hesitating for a long time to also check which edition of rust can be compiled but @CohenArthur convinced me to keep it simple.
Per a quick look, these changes look like (the first part of) how I think they should look like, thanks! In case there are requests for changes, I suggest to first get this reviewed on [email protected] and committed upstream, before pushing to GCC/Rust (here).
patch has been reviewed and approved by Richard Biener, so I think we can merge it here as well. @P-E-P do you want me to take care of the CI issue?
do you want me to take care of the CI issue?
@CohenArthur Yes please. I won't be able to work on it for a while.
@tschwinge I was thinking of pushing it as part of our next upstream? would you rather it was pushed beforehand?
I prefer these generic non-trivial pieces to be integrated incrementally in GCC upstream: one after the other (in a logically meaningful order) instead of in bulk, so that there's some time for testing/stabilization between the individual parts.
alright :) that commit is good to upstream then I think. I'll fix the CI so we can merge it here
@tschwinge I'm a bit lost, should we merge this ? IIRC we already sent this upstream, so we should technically close this PR right ?
@tschwinge I'm a bit lost, should we merge this ? IIRC we already sent this upstream, so we should technically close this PR right ?
I think yes, we'll get the content from upstream when we update our fork. or we can also merge it if the commits match exactly so that it gets skipped once we rebase on gcc's trunk. @P-E-P can you check if there are any differences between what was merged on trunk and this?
@tschwinge I'm a bit lost, should we merge this ? IIRC we already sent this upstream, so we should technically close this PR right ?
I think yes, we'll get the content from upstream when we update our fork. or we can also merge it if the commits match exactly so that it gets skipped once we rebase on gcc's trunk. @P-E-P can you check if there are any differences between what was merged on trunk and this?
There are some differences, this explains my confusion. This PR adds some documentation and modifies the CI, upstream content only has the cargo checking in the autoconf configuration file.
@P-E-P then we should merge this too, but make sure that the commit which touches the build system is exactly the same here as it was pushed on trunk