| Age | Commit message (Collapse) | Author |
|---|
|
There is no need to pass it, we already have self.current_node.
|
|
This detects cases where module A imports a function from B, and C
imports that same function from A instead of B. It's not part of the API
contract of A, and causes innocent refactoring to break things.
|
|
Currently you can only use one of qt4, qt5, qt6 in a single project
when using a machine file because the config-tool lookup for qt only
looks at `qmake` in the machine files, instead of looking up the
binary names directly.
Allow specifying `qmake` `qmake4` `qmake5` and `qmake6`.
This is necessary for gstreamer, which can build separate qt5 and qt6
plugins that are distributed as static libraries, so the user can pick
which one to use.
|
|
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
|
|
It is only used by Environment.get_exe_wrapper() and every callers were
handling None already. Type annotation was wrong, it already could
return None for the case an exe wrapper is needed but none is provided.
|
|
|
|
This also cleans up a couple of internal callers of the internal impl
version that don't set the `check` argument, and therefore trigger a
warning about not setting the check argument.
|
|
|
|
|
|
|
|
|
|
This will always be wrong, because when a directory component is
provided we need to match an exact filename on a manual search path, for
example find_program with dirs: or the current meson.build subdir.
If we ever get this far, shutil.which will do the same "is there a
dirname, if so just check whether the filename exists relative to
cwd"... except that the documented meson lookup path is that we check
relative to meson.build subdir, not relative to the cwd, and the cwd
could be anything, but is probably the root sourcedir.
Since internally, meson does not actually os.chdir into the sourcedir,
it could be absolutely anything at all, though.
...
The actual returned name for shutil.which(name) given a literal pathname
with a directory component is "return name" without adding the absolute
path, which means that this is double-broken. Not only does it find
things we didn't expect, the resulting ExternalProgram object doesn't
have the correct path to the program, so it will report "found" and then
fail to actually run when the current directory is changed, for example
by ninja -C.
Fixes #9262
|
|
|
|
|
|
|
|
|
|
|
|
Dependencies is already a large and complicated package without adding
programs to the list. This also allows us to untangle a bit of spaghetti
that we have.
|
