Fix "Tried to grab file outside current (sub)project" error when subproject exists within
a source tree but it is used through a symlink. Using subprojects as symlinks is very useful
feature when migrating an existing codebase to meson that all sources do not need to be
immediately moved to subprojects folder.
We were poking directly at the node, so if it was a FunctionNode then
this broke. Instead, just do a reverse lookup in the overrides table to
get the original find_program name.
This fixes bogus messages "skipped: feature foo disabled" when
auto_features=disabled. It was reporting the name of the latest
get_option() call instead of the name of the current feature option.
This is especially visible in GStreamer summary where it should show a
different option name for every subproject but instead shows "tools"
everywhere:
```
Subprojects
gst-devtools : NO Feature 'tools' disabled
gst-editing-services : NO Feature 'tools' disabled
...
```
The compiler flag only exists on Visual Studio 2015 or later, or clang-cl,
and using this always can interfere with compiler feature detection when
this flag is not supported.
So, remove '/utf-8' from always_args if we are on Visual Studio 2013 or
earlier.
In commit fb2cdd0fe2 the internal property
was renamed, but one use case of it in raising a MesonException was not
changed to go with it.
This meant that instead of erroring out with:
```
ERROR: GNU symbol visibility arg XXXX not one of: default, internal, hidden, protected, inlineshidden
```
we instead errored out with:
```
AttributeError: 'SharedLibrary' object has no attribute 'symbol_visibility'
```
Fixes#9659
This was added in commit 01be50fdd9 with
zero explanation as a side effect of moving code around. It seems like a
really bad idea and it causes people to view debugging Meson projects on
e.g. debuginfod systems as "painful".
It was originally added because proper detection was not working on
Debian, but that has been fixed since. It was causing annoying warning
by default when prefix is /usr/local that can only be avoided by setting
options.
Move GlobalState to a runtime T.NamedTuple, use it for constructing the
tuple we are passing around rather than expecting mypy to detect that
the one we already have matches.
Instead of reading intro-buildoptions.json, a giant json file containing
every option ever + its current value, use the private file that is
internally used by msetup for e.g. --wipe to restore settings.
This accurately tracks exactly the options specified on the command
line, and avoids lengthy summary messages containing all the overridden
defaults.
It also avoids passing potentially incompatible options, such as
explictly specifying -Dpython.install_env while also having a non-empty
-Dpython.{x}libdir
Fixes#10181
Make use of pyinstaller hooks by creating a hook that updates how the
`mesonbuild` import functions.
This is more or less the same as passing a bajillion arguments to
pyinstaller's CLI, but allows the logic to be self-contained (and
reusable). It becomes more obvious what parts of the process pertain to
pyinstaller, and which parts pertain to MSI/pkg creation.
In case a link is pointing_to an absolute path and we are using $DESTDIR
we fail in case the target is missing.
This is incorrect because we may need to use an absolute path to an
already installed file that is in $DESTDIR.
So if an absolute target is not existing, check if we have such file in
$DESTDIR before failing for real.
This has been broken ever since the original implementation. Due to a
typo, the optimization flag used a zero instead of an uppercase "o",
which the compiler then breaks on during argument parsing because it is
an invalid argument.
Fixes#10267
In print_options() k was a string instead of OptionKey, but
self.yielding_options expects OptionKey. Not sure how this has not been
catched by mypy.
Fix by keeping k as OptionKey which makes self.yielding_options useless.
Fixes: #9503
Although Qt6 has decided these are "internal" commands and should never
be run directly, so they don't get symlinked to /usr/bin at all, and are
only available in the qt_dep.bindir anyway.
But, the general naming pattern should be followed on principle.
Qt now has official guidance for the symlinked names of the tools, which
is great.
Qt now officially calls the tools `fooX` instead of `foo-qtX` where the
major version of Qt is X. Which is not great, because a bit of an
unofficial standard had prior art and now needs to change, and we never
adapted.
Prefer the official name whenever looking up qmake, and in the
testsuite, specifically look only for the official name on versions of
qt which we know should have that.
Fixes regression in commit c211fea513. The
original dependency lookup looked for `qmake-{self.name}`, i.e.
`qmake-qt5`, but when porting to config-tool, it got switched to
`qmake-{self.qtname}` i.e. `qmake-Qt6`, which was bogus and never
worked. As a result, if `qmake-qt5` and `qmake` both existed, and the
latter was NOT qt5, it would only try the less preferred name, and then
fail.
We need to define self.name early enough to define the configtool names,
which means we need to set it before running the configtool __init__()
even though configtool/pkgconfig would also set it to the same value.
Mark the tests as passing on two distros that were failing to detect
qmake due to this issue, and were marked for skipping because we assumed
that the CI skipping there was an expected case rather than an old
regression.
The "frameworks/4 qt" test covers Qt 4 and 5. There is already Qt 6 code
in the test but it is incomplete because translations are missing and Qt
6 requires C++17 or later to compile.
Qt 6.1 moved the location of some binaries from QT_HOST_BINS to
QT_HOST_LIBEXECS as noted in the changelog:
c515ee178f Move build tools to libexec instead of the bin dir
- Tools that are called by the build system and are unlikely to be
called by the user are now installed to the libexec directory.
https://code.qt.io/cgit/qt/qtreleasenotes.git/tree/qt/6.1.0/release-note.txt
It's possible to help the 'qt' module find the tools by adding Qt's
libexec directory to the PATH environment variable, but this manual
workaround is not ideal.
To compensate, meson now needs to look for moc, rcc, uic, etc. in
QT_HOST_LIBEXECS as well as QT_HOST_BINS.
Co-authored-by: Stefan Hajnoczi <stefanha@jammr.net>
Fixes the following ResourceWarnings:
ResourceWarning: subprocess 25556 is still running
_warn("subprocess %s is still running" % self.pid,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
mesonbuild/compilers/mixins/gnu.py:195: ResourceWarning: unclosed file <_io.BufferedReader name=4>
return gnulike_default_include_dirs(tuple(self.exelist), self.language).copy()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
argparse is the gift that keeps on giving, hahaha. Suppress the script
argument when --version is specified to avoid "required argument not
provided" errors, and print the python version.
The version argument is required in order to make this baseline
functional as a resolved python for find_program, which may specify a
version and expect this to work with python itself. Our incomplete CLI
wrapper over the python CLI interface was missing this.
Fixes#10162
Commit a0cade8f introduced a typo and wrongly check for
gtk4-update-icon-cache twice.
If gtk4-update-icon-cache (gtk4) is not found, look for
gtk-update-icon-cache (gtk3) instead.
We print a warning if a compilation database isn't successfully
generated, which is good, because that gives some visibility in case the
user really wanted to use the compdb. But warnings default to being
fatal with --fatal-meson-warnings, which is not so good, because this
isn't a very important warning at all, and we'd rather not error out in
such cases when building works fine and a random bonus IDE feature
doesn't work.
Mark this particular warning as non-fatal.
Fixes side issue in https://github.com/mesonbuild/wrapdb/pull/343#issuecomment-1074545609
While gtk+-3.0 / gtk4 do exist, they have never provided the location of
the gtk-update-icon-cache program as a pkgconfig variable. Trying to
find one anyway, resulted in two things happening:
- a useless dep lookup
- a fatal-meson-warnings error and build failure because the
get_pkgconfig_variable() in question never existed
The desktop-file-utils package is a package solely providing some
command line programs, and has never provided a pkg-config file in the
first place, so this always logged that the dependency was not found and
fell back to normal find_program_impl(), although without
fatal-meson-warnings build errors.
Fixes#10139
The code in the C++ and Fortran compilers' language_stdlib_only_link_flags
method is broken and cannot possibly have ever worked. Instead of
splitting by line, it splits by whitespace and therefore, instead of
the last line of the compiler output:
programs: =/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
libraries: =/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.0
it is only the last field that has its first 11 characters removed.
Instead of reinventing the wheel with a new and brittle pattern,
reuse get_compiler_dirs.
Fixes: 64c267c49 ("compilers: Add default search path stdlib_only_link_flags", 2021-09-25)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When reverting from 0.62 to 0.59, one can see an error like this:
line 1003, in load
obj = pickle.load(f)
File "/Users/pm215/src/qemu-for-merges/meson/mesonbuild/mesonlib/universal.py",
line 2076, in __setstate__
self.__init__(**state) # type: ignore
TypeError: __init__() got an unexpected keyword argument 'module'
FAILED: build.ninja
Raise a MesonException for TypeError as well, so that reconfiguration
proceeds using cmd_line.txt.
Dylan Baker
Nirbheek Chauhan
Vili Väinölä
Eli Schwartz
Tristan Partin
Xavier Claessens
Chun-wei Fan
Jussi Pakkanen
Daniel Mensinger
Paolo Bonzini
Elliott Sales de Andrade
Marco Trevisan (Treviño)
Sergey Fedorov
barracuda156
Stefan Hajnoczi
John Lindgren
Marvin Scholz
Antoine Jacoutot