| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
When cross-compiling, also report build machine compilers in the
compiler report produced by run_project_tests.py
|
|
Add a cross-file for MSVC UWP ARM64.
Bump cidata tag to get an updated install.ps1 script (run by run.ps1)
which sets the vcvars environment correctly when cross-compiling.
Since arranging the correct environment for simultaneous cross and
native 'cl' use is hard, this is test run uses '--cross-only' so we
don't require a native compiler.
Extend '--cross-only' so it also explicitly uses a machine file which
makes all build machine compilers unusable.
|
|
Add '--cross-only' option to run_tests.py, so we can arrange not to run
tests in the 'native' suite when only a cross-compiler is available, as
they can't succeed.
|
|
Split out tests (and parts of tests) which require a native compiler
from the 'common' suite to a new suite called 'native', so we can
selectively avoid running those tests when only a cross-compiler is
available.
Also move test '211 cmake module' to 'cmake' suite, since it appears
that the way we use cmake requires a native compiler.
|
|
on some systems, tests may take over an hour to run--only to find
you might have used an unintended Meson version (e.g. release instead
of dev). This change prints the Meson version at the start of the
run_*tests*.py scripts.
Also, raise SystemExit(main()) is preferred in general over
sys.exit(main())
|
|
This makes the platform_fix_name() machinery for toolchains which don't
have gcc-like filename conventions available to cross testing.
|
|
I don't konw how the heck this has ever worked, but you know.
|
|
Add Azure pipelines CI
|
|
Use the 'CI' environment variable to detect CI environment, rather than a
collection of CI-specific ones.
|
|
|
|
|
|
This reverts commit 0627e9d616dc311b7c9b0ef17301f680ac9e78a7.
Breaks installation: https://github.com/mesonbuild/meson/issues/3647
Will be restored once that can be fixed.
|
|
There are cases when it is useful to wrap the main meson executable with
a script that sets up environment variables, passes --cross-file, etc.
For example, in a Yocto SDK, we need to point to the right meson.cross
so that everything "just works", and we need to alter CC, CXX, etc. In
such cases, it can happen that the "meson" found in the path is actually
a wrapper script that invokes the real meson, which may be in another
location (e.g. "meson.real" or similar).
Currently, in such a situation, meson gets confused because it tries to
invoke itself using the "meson" executable (which points to the wrapper
script) instead of the actual meson (which may be called "meson.real" or
similar). In fact, the wrapper script is not necessarily even Python, so
the whole thing fails.
Fix this by using Python imports to directly find mesonmain.py instead
of trying to detect it heuristically. In addition to fixing the wrapper
issue, this should make the detection logic much more robust.
|
|
|
|
|
|
|
|
|
|
in the same toplevel dir.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
not be determined.
|
|
|
|
|
