From (almost) all points of view, the Xtensa toolchain can be treated as
a regular GCC toolchain.
This patch adds very basic support so that, at least, meson does not
fail when trying to use "xt-xcc" (which makes it possible to use it
without problems).
* coredata: store cross/native files in the same form they will be used
Currently they're forced to absolute paths when they're stored in the
coredata datastructure, then when they're loaded we de-absolute path
them to check if they're in the system wide directories. This doesn't
work at all, since the ninja backend will generat a dependency on a
file that is in the source directory unless the path was already given
as absolute. This results in builds being retriggereed forever due to
a non-existant file.
The right way to do this is to figure out whether the file is in the
build directory, is absolute, or is in one of the system paths at
creation time, and store that path as absolute. Then the code that
reads the file and the code that generates the dependencies in the
ninja backend just takes the computed list and there is no mismatch
between them.
Fixes#5257
* run_unittests: Add a test for correct native file storage
This tests the bug in #5257
When using clang as an objc/objc++ compiler, identify if it's a Windows
targeted compiler, so that GnuLikeCompiler::get_pic_args() doesn't use
'-fPIC', which clang considers an error for the Window target.
Future work: Factor out parsing the clang target string from the
detectors for various languages.
This can be useful to test a local ninja version (for example while developing
changes to ninja or samurai) without modifying the PATH.
The ninja binary that is detected is then hardcoded in the build.ninja
rules for scan-build and clean, so that it is always used until reconfiguration.
This function is used just once. It also seems all policy and no
mechanism (it raises, it calls the same function to do all the work
twice in a simple way). This makes it seem to be as a good candidate for
inlining.
`environment` and `coredata` are woefully intertwined and while this
change doesn't fix that, but at least it makes it easier to follow.
Instead of hard-coding the fact that load_configs() searches for files under
meson/native, pass in the subdirectory allowing the cross-file code to use the
same logic.
We need to match the "clang --version" output on OpenBSD:
$ clang --version | head -1
OpenBSD clang version 7.0.1 (tags/RELEASE_701/final) (based on LLVM 7.0.1)
1. They (and the others) all use PerMachineDefaultable. It's not the
best class, but consistency come first. (It and all of them can be
improved accross the board later.)
2. They use `None` as the default argument so as not to mutate what's
effectively a global variables. (Thanks @dcbaker!)
3. They have a `fallback` field to centralize authority on when
environment variables should be consulted.
First of all, I'd like compilers and other modules that environment.py
currently imports to be able to take these without creating
hard-to-follow module cycles.
Second of all, environment.py's exact purpose seems a bit obscured.
Splitting the data types (and basic pure functions) from the more
complex logic that infers that data seems like a good way to separate
concerns.
This allows the person running configure (either a developer, user, or
distro maintainer) to keep a configuration of where various kinds of
files should end up.
Instead use coredata.compiler_options.<machine>. This brings the cross
and native code paths closer together, since both now use that.
Command line options are interpreted just as before, for backwards
compatibility. This does introduce some funny conditionals. In the
future, I'd like to change the interpretation of command line options so
- The logic is cross-agnostic, i.e. there are no conditions affected by
`is_cross_build()`.
- Compiler args for both the build and host machines can always be
controlled by the command line.
- Compiler args for both machines can always be controlled separately.
First, I noticed there was a dangling use of now-removed cross_info in
the CMake lookup. No tests had caught this, but it means that CMake deps
were totally broken. [It also meant that CMake could not be specified
from a native file.]
In a previous of mine PR which removed cross_info, I overhauled finding
pkg-config a bit so that the native and cross paths were shared. I
noticed that the CMake code greatly resembled the pkg-config code, so I
set about fixing it to match.
I then realized I could refactor things further, separating caching,
finding alternatives, and validating them, while also making the
validations less duplicated. So I ended up changing pkg config lookup a
lot too (and CMake again, to keep matching).
Overall, I think I have the proper ideom for tool lookup now, repated in
two places. I think it would make sense next to share this logic between
these two, compilers, static linkers, and any other tool similarly
specifiable. Either the `BinaryTable` class in environment.py, or a new
class for `Compiler` and friends to subclass, would be good candidates
for this.
* Fixed spelling
* Merged the Buildoptions and Projectinfo interpreter
* Moved detect_compilers to Environment
* Added removed test case
* Split detect_compilers and moved even more code into Environment
* Moved set_default_options to coredata
* Small code simplification in mintro.run
* Move cmd_line_options back to `environment`
We don't actually wish to persist something this unstructured, so we
shouldn't make it a field on `coredata`. It would also be data
denormalization since the information we already store in coredata
depends on the CLI args.
On OpenBSD, the main PowerPC machine is known as macppc, while the processor
family is powerpc:
$ uname -{m,p}
macppc powerpc
$ echo 'import platform; print (platform.machine())' | python3
macppc
$ echo 'import platform; print (platform.processor())' | python3
powerpc
This allows for e.g. GLib configure to properly detect that cpu:
Build machine cpu family: ppc
Build machine cpu: macppc
While it failed before with: WARNING: Unknown CPU family 'macppc' <snip>
It appears that LIB/LINK default to the host architecture if they can't
guess it from the first object. With the MSVC toolchain, resource files
are (usually) compiled to an arch-neutral .res format. Always
explicitly provide a '/MACHINE:' argument to avoid it guessing
incorrectly when cross-compiling.
Building a cross compiler (`build == host != target`) is not cross
compiling. As such, it doesn't make sense to handle it under
`is_cross_build`.
(N.B. Building a standard library for a cross compiler would require
cross compiling, but Meson has support to do such a thing as part of a
compiler build currently.)
We can't just do compiler.has_builtin_define('_M_IX86'), because the
VisualStudioCCompiler class doesn't implement has_builtin_define(), and
getting the compiler to disgorge it's builtin defines isn't easy...
But we can now use the target we stored when we identifed the compiler.
Also update comment appropriately
Store the MSVC compiler target architecture ('x86', 'x64' or 'ARM' (this
is ARM64, I believe)), rather than just if it's x64 or not.
The regex used for target architecture should be ok, based on this list
of [1] version outputs, but we assume x86 if no match, for safety's
sake.
[1] https://stackoverflow.com/a/1233332/1951600
Also detect arch even if cl outputs version to stdout.
Ditto for clang-cl
Future work: is_64 is now only used in get_instruction_set_args()
Starting with VS 2017, `Platform` is not always set (f.ex., if you use
VsDevCmd.bat directly instead of vcvars*.bat), but `VSCMD_ARG_HOST_ARCH`
is always set, so try that first.
samu prints a different message when the build is a no-op, so make
assertBuildIsNoop consider that as well.
Also, if compile_commands.json cannot be found, just skip the test. This
seems reasonable since meson just produces a warning if `ninja -t compdb`
fails.
Finally, only capture stdout in run_meson_command_tests.py, since the
backend may print messages the tests don't recognize to stderr.
Fixes#3405.
Write command line options into a separate file to be able to
reconfigure from scatch in the case coredata cannot be loaded. The most
common case is when we are reconfiguring with a newer meson version.
This means that we should try as much as possible to maintain backward
compatibility for the cmd_line.txt file format.
The main difference with a normal reconfigure is it will use new
default options values and will read again environment variables like
CFLAGS, etc.
Handle clang's cl or clang-cl being in PATH, or set in CC/CXX
Future work: checking the name of the executable here seems like a bad idea.
These compilers will fail to be detected if they are renamed.
v2:
Update compiler.get_argument_type() test
Fix comparisons of id inside CCompiler, backends and elsewhere
v3:
ClangClCPPCompiler should be a subclass of ClangClCCompier, as well
Future work: mocking in test_find_library_patterns() is effected, as we
now test for a subclass, rather than self.id in CCompiler.get_library_naming()
It's much better to directly query the machine in question rather than
do some roundabout "is_cross" thing. This is the first step for much
natve- and cross- code path deduplication.
For existing use cases, pointer equality sufficies, but structural is
much better going forward: these are intended to be immutable
descriptors of the machines.
Instead of just putting these together in the interpreter, put them
together in `environment.py` so Meson's implementation can also better
take advantage of them.
* Enums are strongly typed and make the whole
`gcc_type`/`clang_type`/`icc_type` distinction
redundant.
* Enums also allow extending via member functions,
which makes the code more generalisable.
I believe the intent (from 30d0c2292f) is
that `[binaries]` isn't needed just for "target-only cross" (build ==
host != target). This fixes the code to match that, hopefully clarifying
the control flow in the process, and also improves the message to make
that clear.
Use mesonlib.for_windows or mesonlib.for_cygwin instead of
reimplementing them.
Add CrossBuildInfo.get_host_system to shorten the repeated the code in
the mesonlib.for_<platform> methods.
We already have code to fetch and find binaries specified in a cross
file, so use the same code for exe_wrapper. This allows us to handle
the same corner-cases that were fixed for other cross binaries.
Instead of exposing the endianness in the CPU family, canonicalise the CPU
family to just "ppc64" to match MIPS (which is also bi-endian).
Part of the work for #3842.
* environment: validate cpu_family in cross file
* run_unittests: add unittest to ensure CPU family list in docs and environment matches
* run_unittests: skip compiler options test if not in a git repository
* environment: validate the detected cpu_family
* docs: add 32-bit PowerPC and 32/64-bit MIPS to CPU Families table
Names gathered by booting Linux in Qemu and running:
$ python3
import platform; platform.machine()
Partial fix for #3751
This simplifies a lot of code, and centralize "key=value" parsing in a
single place.
Unknown command line options becomes an hard error instead of
merely printing warning message. It has been warning it would become an
hard error for a while now. This has exceptions though, any
unknown option starting with "<lang>_" or "b_" are ignored because they
depend on which languages gets added and which compiler gets selected.
Also any option for unknown subproject are ignored because they depend
on which subproject actually gets built.
Also write more command line parsing tests. "19 bad command line
options" is removed because bad cmd line option became hard error and
it's covered with new tests in "30 command line".
The 'Platform' envvar may not be set on Visual Studio 2008, at least
when using the SDK 7.0 compilers, so check the 'BUILD_PLAT' envvar so
that we do not mis-detect x64 build environments as x86.
This mistake seems to be a very common hiccup for people trying to use
Meson with MSYS2 on Windows from git or with pip.
msys/python uses POSIX paths with '/' as the root instead of a drive
like `C:/`, and also does not identify the platform as Windows.
This means that configure checks will be wrong, and many build tools
will be unable to parse the paths that are returned by functions in
Python such as shutil.which.
Closes https://github.com/mesonbuild/meson/issues/3653
Instead of using fragile guessing to figure out how to invoke meson,
set the value when meson is run. Also rework how we pass of
meson_script_launcher to regenchecker.py -- it wasn't even being used
With this change, we only need to guess the meson path when running
the tests, and in that case:
1. If MESON_EXE is set in the env, we know how to run meson
for project tests.
2. MESON_EXE is not set, which means we run the configure in-process
for project tests and need to guess what meson to run, so either
- meson.py is found next to run_tests.py, or
- meson, meson.py, or meson.exe is in PATH
Otherwise, you can invoke meson in the following ways:
1. meson is installed, and mesonbuild is available in PYTHONPATH:
- meson, meson.py, meson.exe from PATH
- python3 -m mesonbuild.mesonmain
- python3 /path/to/meson.py
- meson is a shell wrapper to meson.real
2. meson is not installed, and is run from git:
- Absolute path to meson.py
- Relative path to meson.py
- Symlink to meson.py
All these are tested in test_meson_commands.py, except meson.exe since
that involves building the meson msi and installing it.
In gcovr 3.1 the -r/--rootdir argument changed meaning causing
reports generated with gcovr 3.1 to not find the source files
and look for *.gcda in the whole source tree rather than the
build dir.
So, detect gcovr version and if 3.1 give build_root to -r instead
of source_root.
Fix exception handling of missing rustc, by making it look like the other
compiler detectors
Traceback (most recent call last):
File "/wip/meson/mesonbuild/environment.py", line 699, in detect_rust_compiler
p, out = Popen_safe(compiler + ['--version'])[0:2]
[...]
FileNotFoundError: [Errno 2] No such file or directory: 'rustc': 'rustc'
During handling of the above exception, another exception occurred:
[...]
File "/wip/meson/mesonbuild/environment.py", line 701, in detect_rust_compiler
popen_exceptions[compiler] = e
TypeError: unhashable type: 'list'
According to Python documentation[1] dirname and basename
are defined as follows:
os.path.dirname() = os.path.split()[0]
os.path.basename() = os.path.split()[1]
For the purpose of better readability split() is replaced
by appropriate function if only one part of returned tuple
is used.
[1]: https://docs.python.org/3/library/os.path.html#os.path.split
They now are published by the D Language Foundation, and not Digital
Mars. Therefore, their signature has changed slightly.
(We can not check for 'DMD', because that string appears in every
compiler version output to denote the frontend version used by the
compiler).
See issue #2762
Adds full_version to class Compiler. If set full_version will be printed
additionally.
Added support for CCompiler and CPPCompiler
Added support for gcc/g++, clang/clang++, icc.
Fernando Ramos