Explicitly note the reason environment variables or constant overrides can not be used in machine files.

[Kagetsuki]

I'd like to add to the documentation for cross compiling that machine files do not allow environment variables or configurable or overridable constants and also why they don't allow them.

Basically I've been trying to use environment variables in a cross compile machine file and couldn't figure out why it wasn't working. The documentation says nothing about environment variables (and I already knew overriding constants was not possible - again when trying to do so and only later finding out when digging through issues that it was not possible). Searching yielded multiple threads loosely related to this subject, and many threads about people asking how to pass options or override constants defined in machine files with no actual answers or reason why there was no such implementation. Then I ran across this specific post: #5859 (comment)
Which states:

As a project we've been very vocal that cross compilation settings on the command line is not happening

But I can find no post nor reasoning on this, and I still do not know why environment variables can not be used or the reasoning behind making machines files so strictly static. Until this is clearly written in the documentation there will continue to be issues raised about this and people wasting time searching for solutions that do not exist. I'd modify the documents myself and put up a PR but I still don't actually know the reason and I'd rather not guess and misrepresent it - so if anyone can point me to this or clarify it would be much appreciated.

To clarify, while I'd surely appreciate such functionality, I'm assuming there's a good reason for not having it - clearly noting that would surely help others understand this is by design and simply not a missing feature.

[eli-schwartz]

I think this is a @jpakkane question. I can't really answer it myself because I'm not entirely clear why it's a problem and would be willing to have this work if it were up to me.

[eli-schwartz]

Note that we do want to guarantee that the value is preserved across a reconfigure, but this is already possible by recording the explicitly set options regardless of where they come from, and we support it like this for native environment variables...

[Kagetsuki]

I'm guessing it's something like meson wanting one specific configuration per system which should be universal across systems, and also passing a bunch of arguments during configuration is clumsy and ugly. Further, in cases like Android where it would basically need to be assumed all environment variables are already set and have been set correctly would require additional documentation per-project and would mean the configuration would fail for everyone who didn't read the documentation beforehand. So, my assumption is, the reason it's this way is to force conciseness and reduce pre-configuration steps which would be different per project or per system - every project should be buildable with the same arguments. But these are just guesses and I feel like there's a more concise design decision that probably went into this.

To clarify, where I and so many others ran into problems was the Android NDK and embedded system compilers:

• The NDK has no "standard" install path, you can't put the tools in the NDK on the standard path because some of them conflict/have the same names as standard tools, and the compilers are prefixed with both the architecture and API level - and everyone could be using a different API level. There are standard environment variables to set the SDK/tools root and other defaults that many people who use the NDK will already have set.
• Embedded system SDKs usually come with a somewhat standard layout and tools that have the same names as those found on the system. These are rarely installed system-wide, so normally you just set a prefix as an argument during configuration or an environment variable.

One of the devs noted in a comment and I also very much share this sentiment now: These are design issues with these specific SDKs/toolsets, not Meson. Regardless, without allowing for environment variables or overridable constants in the machine files; these two scenarios result in effectively everyone who wants to cross compile needing to basically edit or generate one or (in the case of Android maybe 4 or more) machine files extremely specific to their system. The need to do this, and the [design] reason why it's this way, was clearly noted in the documentation I think it would be helpful and save people like me some time and confusion (and hopefully reduce the amount of issues about the subject in the future).

[Kagetsuki]

Note: a big part of this problem can already be remedied from 1.3.0 by leveraging the @GLOBAL_SOURCE_ROOT@ and @DIRNAME@ tokens (and perhaps symlinks). These features are noted at the bottom of the constants section and possible solution to the embedded system SDK issue I raised above is outlined here: https://mesonbuild.com/Machine-files.html#constants . Things like setting Android API level wouldn't be covered by this but in a lot of situations that's probably not a major issue in many situations.

[xclaesse]

I still have this PR to allow setting constants in cross file from CLI: #5859

I still think we should do something like that.

[xclaesse]

At least now with @DIRNAME@ if an SDK, such as android, wants to ship a cross file, that can be relocatable.

[Kagetsuki]

@xclaesse I definitely saw that during my searches. I also personally think there should be a way to do overrides but I hate to say it, I kind of agree with the Meson core at this point about passing (possibly project/machine file specific) arguments on the command line -- but I also don't know specifically why the design decision was made this way so my reasoning could be completely different.

Depending on the clarification of that design decision I was actually considering making a proposal to be able to set constants be overridable by environment variables. EG:

[constants]
root_path = %ANDROID_HOME% || '/opt/Android/'

Where if ANDROID_HOME isn't set it would fall back to '/opt/Android'. This would also allow arguments to be passed on the call by prefixing the environment variable like ANDROID_HOME=$HOME/Android meson setup --cross-file=../cross/android-arm64.ini .., which is essentially just as flexible as passing things like --constant "android_home=...".

Totally not trying to discount your consideration or work on this issue though this was just the idea that I had.