* docs/reference-manual: link to references tables
Currently the reference manual entries for *machine.cpu_family() and
*machine.system() have incomplete (and wrong) information. Rather than
continue to duplicate this information just link to the reference
tables.
* docs/Reference-manual: fix link target
The IDs in hotdoc are always lowered, so this pointed to the right page,
but didn't go to the heading.
* docs/Reference-manual: link compiler.get_id directly to tables
Currently it goes round about to an entry that doesn't add much
information and points to the reference table. Instead just point to the
reference table.
Mention that the dependency name will also be searched for as a framework on
OSX.
Note that additional dependency-specific keywords may be used by custom
dependency lookup.
PR #1852 only adds mention of this to the release note.
I think it's useful to have a list of all dependency names which are treated
specifically in Dependency.md, so add 'thread' and 'openmp'.
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.
Currently, commandrunner breaks when we give options to python because
it assumes python commands are in the form "python script.py", rather
than "python -u script.py" or "python -u -m module script.py". Extend it
to be more resilient and correctly parse python options.
Currently, ExternalProgram get_path() assumes the last component in the
path is always the actual command path. However, this is not always
right. For example, in the command "python -u", we should return
"python" and not "-u". However, in other cases, like "python script.py",
then the last component is the right one.
The heuristic that seems to capture this is to use the last argument
that is still a file. This means options get ignored, but "python
script.py" still works. Let's use this heuristic, at least for now.
This checks not only for existence, but also for usability of the
header, which means it does a full compilation and not just
pre-processing or __has_include.
Fixes https://github.com/mesonbuild/meson/issues/2246