This will allow using gtk-doc as a subproject instead of having to
install it on the system. It also has the side effect of failing at
configuration time with a proper message if gtkdoc is not installed,
instead of failing at build time with a python backtrace.
There are two variables that CMake takes into account during
find_package() in cross-compiled environments, which are: CMAKE_SYSROOT
and CMAKE_FIND_ROOT_PATH. Those are used in cmFindCommon::RerootPaths()
function, which blindly prepends all search paths with those specified
via CMAKE_SYSROOT and CMAKE_FIND_ROOT_PATH.
Extend search paths by using CMAKE_SYSROOT and CMAKE_FIND_ROOT_PATH in a
similar way as CMake does, so we successfully find CMake packages
information in cross-compiled environments.
Otherwise having an output directory matching the name of the cross file
in the current working directory will cause an error. This patch instead
collects any invalid names and prints them along with the error message
when no valid file can be found.
Fixes#5640
At configure time, kconfig can read from configure_file().
"test cases/kconfig/4 load_config builddir/meson.build" was already
showing a workaround, now it actually can take configure_file input
directly.
To make Fortran tests useful on Windows, the library_type should default to static,
unless needed to specifically test shared. Shared Fortran libs on Windows for
non-Gfortran compilers is fragile requiring proprietary code syntax.
* PGI C++ PCH enable
PGI compilers support precompiled headers for C++ only.
The common/13 pch test passes if run manually with no spaces in the build path.
However, since Meson run_project_tests.py makes temporary build directories
with spaces in each tests, PGI --pch_dir can't handle this and fails.
So we skip the test for PGI despite it working for usual case with no-spaces
in build dir.
Note: it's fine to have spaces in full path for sourcedir, just no spaces in
relative path to builddir.
* doc
There are two problems, one is that it assumes -flto is the argument
to do LTO/WPO, which isn't true of ICC and MSVC (and presumably)
others. It's also incorrect because it assumes that the compiler and
linker will always be the same, which isn't necessarily true. You
could combine GCC with Apple's linker, or clang with link.exe, which
use different arguments.
I started out just annotating, but realized there is a lot of really
silly duplication of methods in this module. Nearly all of the methods
return [], but each class implemented the same methods over and over!
I've fixed this by moving the default implementation down into the
`StaticLinker` class, and then overriding as necessary in the derived
classes.
This is used in a lot of places, having a single way to reference it is
convenient. It's placed under a typing.TYPE_CHECKING guard to mimimize
runtime impact
"exe.is_cross and exe.needs_exe_wrapper" is the same condition under which
meson chooses whether to include the exe_wrapper. meson_exe has an assertion
for that, but now that meson_exe does not need anymore exe.is_cross,
we can simplify the code if we just "trust" meson to do the right thing.
Remove both fields from ExecutableSerialisation and just test the presence
of the wrapper, and also remove the executable basename which is only
used to "beautify" an assertion failure.
Move the magic to execute jar and .exe files from "meson --internal exe"
to the backend, so that "ninja -v" shows more clearly what is happening.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If meson_exe is only being used to capture the output of the command,
we can skip going through a pickled ExecutableSerialization object.
This makes "ninja -v" output more useful.
Return the command line from serialize_executable, which is then
renamed to as_meson_exe_cmdline. This avoids repeating code that
is common to custom targets and generators.
Xavier Claessens
Marcin Niestroj
Jussi Pakkanen
Michael Hirsch, Ph.D
Dylan Baker
Marc-André Lureau
Daniel Mensinger
Michael Hirsch, Ph.D
Thibault Saunier
Nirbheek Chauhan
Jeremy Philippe
Paolo Bonzini