Skip to content

Commit

Permalink
Naturally use env vars a bit more to match Autoconf
Browse files Browse the repository at this point in the history
PR #6363 made it so our interpretation of env vars no longer clashed
with Autoconf's: if both Meson and Autoconf would read and env var, both
would do the same things with the value they read.

However, there were still cases that autoconf would read an env var when
meson wouldn't:

 - Autoconf would use `CC` in cross builds too

 - Autoconf would use `CC_FOR_BUILD` in native builds too.

There's no reason Meson can't also do this--if native cross files
overwrite rather than replace env vars, cross files can also overwrite
rather than replace env vars.

Because variables like `CC` are so ubiquitous, and because ignoring them
in cross builds just makes those builds liable to break (and things more
complicated in general), we bring Meson's behavior in line with
Autoconf's.

(cherry picked from commit 097dfc0)
PR #6806 was accidentally merged, then reverted.
  • Loading branch information
Ericson2314 committed May 16, 2020
1 parent 3d41fa9 commit 52f1107
Show file tree
Hide file tree
Showing 4 changed files with 37 additions and 12 deletions.
15 changes: 8 additions & 7 deletions docs/markdown/howtox.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,15 +12,16 @@ When first running Meson, set it in an environment variable.
$ CC=mycc meson <options>
```

Note that environment variables like `CC` only works in native builds. The `CC`
refers to the compiler for the host platform, that is the compiler used to
compile programs that run on the machine we will eventually install the project
on. The compiler used to build things that run on the machine we do the
building can be specified with `CC_FOR_BUILD`. You can use it in cross builds.
Note that environment variables like `CC` only refer to the host platform in
cross builds. That is, `CC` refers to the compiler used to compile programs
that run on the machine we will eventually install the project on. The compiler
used to build things that run on the machine we do the building can be specified
with `CC_FOR_BUILD`. You can always used `CC_FOR_BUILD`, but for native builds
it is less well known because Meson (and Autotools) will default `CC_FOR_BUILD`
with `CC`.

Note that environment variables are never the idiomatic way to do anything with
Meson, however. It is better to use the native and cross files. And the tools
for the host platform in cross builds can only be specified with a cross file.
Meson, however. It is better to use the native and cross files.

There is a table of all environment variables supported [Here](Reference-tables.md#compiler-and-linker-selection-variables)

Expand Down
25 changes: 25 additions & 0 deletions docs/markdown/snippets/env_vars_and_cross.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
## Read standard environment variables in more cases

Make variables like `CC` and `CC_FOR_BUILD` never be ignored, regardless of
whether the overall build is native of cross. [Config files, which one should
greatly prefer over environment variables, still take precedence, however.]

As of version 0.54, variables like `CC` controls the host platform options (if
not set by a config file) in native builds, while variables like `CC_FOR_BUILD`
does it for the build platform in cross builds. The intent was to limit the use
of environment variables to a bare minimum and encourage putting everything in
config files.

However, the special-casing of cross vs native means infrastructure around
meson packages like distro packages is harder to test, and cross builds in
particular are more likely to bit-rot if native builds are exclusively tested,
as is often the case.

By making `CC` always control the host platform, and `CC_FOR_BUILD` for build
the native platform, we remove much special casing. We do leave in place that
variables like `CC` also affect the build platform in native builds if
`CC_FOR_BUILD` is not set, as this is the standard.

As an added bonus, this change, including the `build = host` fallback rules
just described, brings us in full conformance with how Autoconf reads
environment variables.
4 changes: 2 additions & 2 deletions mesonbuild/envconfig.py
Original file line number Diff line number Diff line change
Expand Up @@ -120,9 +120,9 @@ def get_env_var_pair(for_machine: MachineChoice,
# compiling we fall back on the unprefixed host version. This
# allows native builds to never need to worry about the 'BUILD_*'
# ones.
([var_name + '_FOR_BUILD'] if is_cross else [var_name]),
[var_name + '_FOR_BUILD'] + ([] if is_cross else [var_name]),
# Always just the unprefixed host verions
[var_name]
[var_name],
)[for_machine]
for var in candidates:
value = os.environ.get(var)
Expand Down
5 changes: 2 additions & 3 deletions run_unittests.py
Original file line number Diff line number Diff line change
Expand Up @@ -6510,11 +6510,10 @@ def test_identity_cross_env(self):
testdir = os.path.join(self.unit_test_dir, '61 identity cross')
env = {
'CC_FOR_BUILD': '"' + os.path.join(testdir, 'build_wrapper.py') + '"',
'CC': '"' + os.path.join(testdir, 'host_wrapper.py') + '"',
}
crossfile = tempfile.NamedTemporaryFile(mode='w')
crossfile.write('''[binaries]
c = ['{0}']
'''.format(os.path.join(testdir, 'host_wrapper.py')))
crossfile.write('')
crossfile.flush()
self.meson_cross_file = crossfile.name
# TODO should someday be explicit about build platform only here
Expand Down

0 comments on commit 52f1107

Please sign in to comment.