In Fedora we don't care about prefix, we want to ensure that libdir
is /usr/lib64, localedir is /usr/share/locale, and cetera.
Additionally, we don't need to ensure that prefix is absolute as we
check it in main.
Fixes: cc19bf0f45 ("Move option validation in objects rather than doing it only in the conf script.")
Closes: https://github.com/mesonbuild/meson/issues/869
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
When installing Meson, distutils may choose to put shim scripts in the
`PATH` that only set up the egg requirements before launching the real
`meson.py` contained in the egg.
This means that `__file__` points to the real `meson.py` file, but
launching it directly is doomed to fail as it's missing the metadata
contained in the shim to set up the path egg, resulting in errors when
trying to import the `mesonbuild` module.
A similar issue affects Meson when installed as a zipapp, with the
current code going great lengths to figure out how to relaunch itself.
Using `argv[0]` avoids these issues as it gives us the way the current
executable has been launched, so we are pretty much guaranteed that
using it will create another instance of the same executable. We only
need to resolve relative paths as the current working directory may
get changed before re-launching the script, and using `realpath()` for
that saves us the trouble of manually resolving links and getting caught
in endless loops.
This also mean that `meson_script_file` no longer necessarily point to a
absolute file, so rename it to `_launcher` which hopefully would be less
prone to inducing false assumptions.
After c01b183e5, the mtime of coredata.dat is always newer than all the
other build files, which made regen_checker think that they always had
to be regenerated. Now we set the mtime of the file to a value before
the build files are generated and that makes everything behave as it did
earlier.
Otherwise we'll mark the build directory as successfully configured even
if there's an error while doing the actual generation.
Reported on IRC by 'sdgsgad'
When a CustomTarget is run with a command that is an executable built
by the project which also has a DLL built in the same project as a
dependency, the EXE can't run on Windows because the DLL can't be found.
On UNIX-like systems, we set the RPATH using the linker so these
dependencies can be found, but on Windows the only way is to set the
PATH environment variable.
The same problem exists for tests, so we reuse that infrastructure by
creating a new meson_exe.py script that can be used as a wrapper to run
CustomTarget commands on Windows. This can later also be extended to add
support for setting an environment while calling the command needed to
generate a CustomTarget: https://github.com/mesonbuild/meson/issues/266
Patrick Griffis
Igor Gnatenko
Jussi Pakkanen
Emanuele Aina
Elliott Sales de Andrade
Nirbheek Chauhan
Nicolas Schneider
Nirbheek Chauhan
Hemmo Nieminen
Tim-Philipp Müller
Thibault Saunier
Yoav Alon
Wink Saville