-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
rust: Require native: true
for proc-macro
targets and allow linki…
#11743
Conversation
13f3a7f
to
105b7fd
Compare
@@ -8,6 +8,7 @@ pm = shared_library( | |||
'proc_macro_examples', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of lines above, why is this test disabled on non-Linux, how does it fail? Theoretically there shouldn't be anything special required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sdroege some of the tests are disabled on certain platforms because toolchains might not be setup on those platforms (work needed) or tests can take too long. In this case, you are probably running into the second option. Azure CI takes an ungodly amount of time and will timeout frequently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could very well be historical reasons that have been fixed since then. Feel free to open a separate PR that unskip them and see how it goes on the CI.
@@ -8,6 +8,7 @@ pm = shared_library( | |||
'proc_macro_examples', | |||
'proc.rs', | |||
rust_crate_type : 'proc-macro', | |||
native: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would I enable this test on the CI for actually doing cross-compilation? I see that there are Linux/armhf and mingw64 cross tests in the CI. Should I add the corresponding rust toolchains there? How would I then enable this test to actually run?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See e.g. cross/linux-mingw-w64-64bit.txt
You just need to set up the rust compiler as a cross binary, and configure the corresponding .json file to change e.g. "tests": ["common", "cmake"],
to specify which run_project_tests.py suites are now supported by that cross test configuration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should add native: true
here, the whole point of this PR is to test it's the default.
Giving it a try at cross rust compilation in CI there: #11990.
105b7fd
to
9d61c0f
Compare
Is there ever a case where you'd want to compile |
That would also work, I guess. The only case I could think of is when someone wants to compile the proc-macro on some build machine, and then compile something with that proc-macro on the target machine. Not sure if that's something worth worrying about? |
You'd have to install one to do that. Is this expected to work? |
You'd have to install it or copy it around somehow manually, yes. I wouldn't expect that to work but with enough motivation and carefully set up environments you can probably make it work. It's something I wouldn't want to support though. |
So I guess the summary here would be to a) default to For using a proc-macro built "elsewhere" (c) you need to ensure that exactly the same toolchain version is used and then it can theoretically work but I don't think this is explicitly supported by rustc either. If it's literally the same toolchain then there's no reason why it shouldn't work (you'd somehow need to tell the compiler where to find it though), if you build on a cross toolchain and then use it on the target with the same toolchain version it may or may not work. |
9d61c0f
to
ef0c71d
Compare
…ng into targets for other platforms proc-macros are basically compiler extensions and must be compiled for the build machine so that the compiler can load and execute it at runtime. Without this, cross-compilation of targets that use proc-macro dependencies is going to fail. Fixes mesonbuild#11702
ef0c71d
to
7e7749d
Compare
Ping. What's the status of wiring up tests? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From a code point of view this looks fine to me, I still wonder long-term if we want to deprecate the proc-macro crate type and just add a rust_module.proc_macro()
helper to avoid this. I think this is a net improvement over what we have, so I'm happy
I'm also in favor of landing this after the rc if necessary. From my point of view this is a bug fix, since Meson allows something that cannot work in practice |
Agreed -- once it is tested in CI I'm happy with merging it even past the rc freeze. |
Doing tests looks like an adventure that will take me a couple of hours once I figured out how the CI works exactly and waited for a few dozen failed runs in the meantime, so I didn't get to that yet and it will probably take a while. I'd like to have this merged but I also think that having tests on the CI for this is important because otherwise it will just stop working again sooner or later :) If someone wants to take this over please go ahead, otherwise I'll get to it once I have a bigger slot of time available. |
@@ -1408,7 +1408,7 @@ def link(self, target): | |||
msg = f"Can't link non-PIC static library {t.name!r} into shared library {self.name!r}. " | |||
msg += "Use the 'pic' option to static_library to build with PIC." | |||
raise InvalidArguments(msg) | |||
if self.for_machine is not t.for_machine: | |||
if self.for_machine is not t.for_machine and (not t.uses_rust() or t.rust_crate_type != 'proc-macro'): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think t
can be a CustomTarget
which does not implement uses_rust()
. What about:
if self.for_machine is not t.for_machine and (not t.uses_rust() or t.rust_crate_type != 'proc-macro'): | |
if self.for_machine is not t.for_machine and (not isinstance(t, SharedLibrary) or t.rust_crate_type != 'proc-macro'): |
@@ -2328,6 +2328,13 @@ def process_kwargs(self, kwargs): | |||
else: | |||
raise InvalidArguments(f'Invalid rust_crate_type "{rust_crate_type}": must be a string.') | |||
if rust_crate_type == 'proc-macro': | |||
if 'native' not in kwargs: | |||
kwargs['native'] = True | |||
if not kwargs.get('native', False): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You set it to true
above if it's missing, so the False
cannot be used.
if not kwargs.get('native', False): | |
if not kwargs['native']: |
if self.environment.is_cross_build(): | ||
raise InvalidArguments('Rust "proc-macro" crate type requires "native: true". This will fail in a cross-build.') | ||
else: | ||
mlog.warning('Rust "proc-macro" crate type requires "native: true". This will fail in a cross-build.') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does not require "native: true", that's the default in this case. I think it should always be an hard error, no need to downgrade to a warning if it's not a cross build. To happen, user must have explicitely wrote:
shared_library(..., rust_crate_type: 'proc-macros', native: false)
which is always wrong.
What about:
if self.environment.is_cross_build(): | |
raise InvalidArguments('Rust "proc-macro" crate type requires "native: true". This will fail in a cross-build.') | |
else: | |
mlog.warning('Rust "proc-macro" crate type requires "native: true". This will fail in a cross-build.') | |
raise InvalidArguments('Rust "proc-macro" crate type does not allow "native: false".') |
rust: Require `native: true` for `proc-macro` targets and allow linking into targets for other platforms proc-macros are basically compiler extensions and must be compiled for the build machine so that the compiler can load and execute it at runtime. Without this, cross-compilation of targets that use proc-macro dependencies is going to fail. Fixes mesonbuild#11702
rust: Require `native: true` for `proc-macro` targets and allow linking into targets for other platforms proc-macros are basically compiler extensions and must be compiled for the build machine so that the compiler can load and execute it at runtime. Without this, cross-compilation of targets that use proc-macro dependencies is going to fail. Fixes mesonbuild#11702
I'm encountering a bit more trouble cross-compiling Mesa for i686; the Meson adds the |
@heftig Can you please open a separate issue? A minimal test case would be nice too because I failed to reproduce. |
Closing this PR because it is included into #11714 which does a bigger refactoring of proc-macro. |
…ng into targets for other platforms
proc-macros are basically compiler extensions and must be compiled for the build machine so that the compiler can load and execute it at runtime.
Without this, cross-compilation of targets that use proc-macro dependencies is going to fail.
Fixes #11702