-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Meson's tool env var interpretation clashes with Autoconf's, leading to disto packaging issue #3969
Comments
Yes, we do have an inconsistency here with Autoconf. It is too late to change this, IMO. |
The mechanism is rejected, but the concept is not. We really want it because environment variables are not the greatest way to specify configuration, particularly paths. For instance, there is no way to reliably disambiguate spaces in paths from spaces separating arguments. You could in theory use shell quoting, but in practice most tools don't implement it (meson does, though) so it's difficult to use it consistently. |
No this isn't true. It's very important to understand that the build, host, and target machines are defined for native and cross builds alike:
Note that nothing here says the machines are different. For native builds they all coincide, for cross builds they don't. I know I sound like a pedant in the previous paragraph, but this shift in mindset is key to removing all the
In short, if we allow
If the last rule is eventually dropped after transition period, the rule becomes:
Which is Autoconf's, plus the C.f. Meson's rule today is:
|
Environment variables are hiddne global state. And thus terrible. We try to minimize their use as much as possible in favor of command line arguments and conf files. It is extremely unlikely we will add more environment variables in in Meson and in fact would like to reduce them further if possible. |
@jpakkane it would also be fine with me if Meson stopped interpreting I thought https://mesonbuild.com/Quick-guide.html#using-meson-as-a-distro-packager meant we had to keep around some env vars for distro's sake, and if we must keep |
I would love to drop Also we'd first need to get some other way of defining the compiler, such as the build machine file discussed elsewhere. |
Alright. Then let's just let this one sit until #3972 is figured out. |
I understand the desire to avoid environment variables; in NixOS they have caused a bunch of problems when different build systems interpret the same variables in a different way. For instance, a bunch of packages give incomprehensible link errors when How about having the proposed |
@jpakkane For the record in #3782 someone else set |
I don't see #3972 having a single mention that the file would override |
@dezgeg Amended the OP to clarify that. |
We hit a problem with this in VLCs contrib system too and had to special-case things for meson, so personally while I think meson should not start interpreting the env variables in the way autotools does, for cross, I think it should completely ignore them as else it just clashes with how every other build system I know of handles this, which is an annoying problem. While it might be easy to suggest "just unset all those env variables", this is in some cases not easily doable. But yes this is quite a big change with regard to backwards compatibility so not sure if it is not too late for that now. |
@ePirat I edited the OP to mention what's landed since I opened the issue, and what concrete steps I recommend now. I take it you at least agree with step 1, without which there would be no way to specify those binaries if cross builds ignore the env vars? |
Yes, definitely. |
Oops, brain fart. |
But there is the analogous change addition of |
#6363 is the PR for this, FYI |
With Autoconf (along with ideomatic macros):
<TOOL>_FOR_BUILD
affects the build platform<TOOL>
affects the host platform<TOOL>_FOR_TARGET
affects the target platform.For example, if I am building a Canadian cross GCC:
CC_FOR_BUILD
builds tools on the fly used to generate some repetitive C code.CC
builds the cross compiler itselfCC_FOR_TARGET
buildslibgcc
and other runtime libraries, since the newly-built compiler cannot be run to build them.Meson however assumes
CC
,AS
and friends always target the native platform, whatever that is. Notice how in terms of "build", "host" and "target", rather than "native", this means the meaning of these environment variables in Meson is conditional on whether we are cross compiling or not.CC
is explicitly used in the native case for building things morally for the host platform (i.e. stuff that will be installed), but not in the cross case.In the distro I package use, NixOS, We define the variables according to Autoconf https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/bintools-wrapper/setup-hook.sh#L66 here. (Granted there's a number of abstractions going on so I don't expect that to be clear.) This works in the fast majority of cases, but creates issues for cross-compiling our packages that use Meson, even though we also create a cross file just for meson. It sees our
CC
, targeting the host platform, and tries to use that rather thanCC_FOR_BUILD
for building code gen tools. This fails as the resulting binaries cannot be run at build time.At a minimum, this issue would be solved if Meson would ignore
CC
for building code gen tools in the cross case. It would be nicer still if Meson would read<TOOL>_FOR_BUILD
rather than<TOOL>
in that cross case. Even better would be using<TOOL>_FOR_BUILD
for building code gen stuff in all cases: this would make the native in cross cases more consistent. (It would also help with e.g. optimizing release builds but not codegen tools used for release buidls, FWIW.)Since environment variables are not an idiomatic way to give Meson information, it would also be nice to specify the tools with (something like) the cross file. I opened #3282 for this purpose, but it got no response. Note that this is very analogous to specifying
build_machine
information more broadly, I proposed in #3689 but seems to be approaching rejected.CC @dezgeg @jtojnar
So since I opened this issue, we've had two big changes internally:
BinaryTable
class.This makes solving this a lot easier. I suggest:
Native files have adone, my mistake.[binaries]
section, which functions in the obvious way (like the env vars today)FOO_FOR_BUILD
always overridesFOO
for the binaries for build (environment.binaries.build
).FOO_FOR_BUILD
is the only way to specify for-build binaries for cross builds. PlainFOO
only controls host binaries for cross builds.In particular, 1 and 2 and land in isolation, and are not breaking changes. Only 3 is, and by then the idiomatic way to control binaries would be the native file anyways.
CFLAGS
and friends are more complicated, as the code paths are still wildly different.The text was updated successfully, but these errors were encountered: