-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check for cargo when building rust language #2942
base: master
Are you sure you want to change the base?
Conversation
Is it expected that GCC Rust build and test / build-and-check-gcc-48 failed here: |
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 gcc-patches@gcc.gnu.org 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 " |
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. |
c60ce2b
to
9876f36
Compare
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? |
@CohenArthur Yes please. I won't be able to work on it for a while. |
So, are you going to |
@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 |
Cargo presence will be checked during configuration in the future, we therefore need to add it's location to PATH. ChangeLog: * .github/workflows/ccpp.yml: Add cargo to PATH. Signed-off-by: Pierre-Emmanuel Patry <pierre-emmanuel.patry@embecosm.com>
Prevent rust language from building when cargo is missing. config/ChangeLog: * acx.m4: Add a macro to check for rust components. ChangeLog: * configure: Regenerate. * configure.ac: Emit an error message when cargo is missing. Signed-off-by: Pierre-Emmanuel Patry <pierre-emmanuel.patry@embecosm.com>
Cargo is temporarily required in order to build some parts of GCC rust frontend. This requirement was not mentioned in the documentation. gcc/ChangeLog: * doc/install.texi: Mention cargo requirement. Signed-off-by: Pierre-Emmanuel Patry <pierre-emmanuel.patry@embecosm.com>
ChangeLog: * .github/workflows/ccpp.yml: Add sourcing of cargo's environment file.
e923d78
to
7b55892
Compare
The warning shown in gcc/doc/install.texi has been moved down slightly due to adding new lines for the Rust documentation. ChangeLog: * .github/bors_log_expected_warnings: Fix line number of install.texi warning.
@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 |
Prevent rust language from building when cargo is missing.