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.
The added format argument for configure_file allows to specify the kind of
file that is treated. It defaults to 'meson', but can also have the 'cmake'
or 'cmake@' value to treat config.h.in files in the cmake format with #cmakedefine
statements.
Starting from 8fc4244187, tests
failed on my system (python 3.6 arch) because
shutil.which('meson.py') returns 'meson.py', not './meson.py'.
Refactor that codepath by using os.path.isabs instead of
"m_dir == '.'", also remove the adjacent comment because
it doesn't make much sense.
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
teach detect_meson_py_location() that meson.py is not the
only one meson executable (there's wraptool + legacy scripts)
that could be installed to the PATH folder
fixes#2810
We can now specify the library type we want to search for, and whether
we want to prefer static libraries over shared ones or the other way
around. This functionality is not exposed to build files yet.
Otherwise we might end up with wrapper holders in the Build object and
pickling will then fail, defeating the purpose of the holder objects.
Closes https://github.com/mesonbuild/meson/issues/2211
Currently if flatten() is passed a non-list object, it returns that
object. This is surprising behavior, and prone to causing serious and
numerous problems, since many objects implement the iterable interface,
and thus can be used in cases a list is expected, but with undesirable
results.
Salamandar
Nirbheek Chauhan
Martin Kelly
Jasper Lievisse Adriaanse
Robin
David Fort
Jussi Pakkanen
Mathieu Duponchelle
Robert Bragg
Aleksey Filippov
Salamandar
Dylan Baker
Alexey Stukalov
Benjamin Redelings
Joergen Ibsen
Alexis Jeandet
Jérôme Duval
Michal Koutný
Christoph Reiter