| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
We use a dummy project with a vague name and try to find flags for it
based on the installable pkg-config files. This sort of works,
generally, because it attempts to match `-lct` which doesn't exist
because the test case isn't installed, and that link argument is passed
directly through.
Except, sometimes that library does exist. It is provided by the
"freetds" project, which may be a dependency other tools. In that case,
Meson finds a library, and the `dependency()` resolves to
`/usr/lib/libct.so` and the test fails.
Fortunately, we do have an API to say that we really want to get back
the same flags pkg-config returned. Use this.
|
|
We test a couple ways of running the meson command, and double check
that the debug logs record the meson command used (including python).
But when running the meson command as an executable instead of as a
python script, we see whichever version `env` in the shebang sees.
Fix this by mocking the python command as well.
|
|
*.qrc files converted to C++ sources could make use of Qt headers, and
in practice for qt4 they seem to. Since this is Qt code to begin with,
it makes sense to depend on the Qt being targeted regardless of version.
|
|
|
|
Because spaces aren't allowed and result in compilation failures
|
|
When we create a test from a non-executable, we weren't copying the
generated sources, just the static ones.
|
|
Which thinks `sources` should be `List[File]`, but they should be
`List[SourceOutputs]`
|
|
We need to run it as an external command at build time anyway, and we
detect it by looking it up as an ExternalProgram. It seems odd to then
import it into Meson's python interpreter and run the main function.
Moreover, this errors out when you are running two different pythons,
one for Meson and one for hotdoc. For example, when hotdoc is installed
normally, but you're testing Meson against a nondefault newer version of
python.
|
|
We have divergent implementations of loading a pickled *.dat file. The
Build class loader has a better error message. But the generic loader
handles TypeError and ModuleNotFoundError. Merge the implementations,
and use it for Build as well.
Fixes #11051
|
|
The original version will output something like `xtakes no arguments`, and the modified version will correctly output `x takes no arguments`.
|
|
Since commit 1420d0daceb10cafb52a7405f157032a5cc811a5 we use coredata's
cmd_line.txt handler to get the right setup arguments. But there's a bug
in that -- it mishandles cross/native files, producing invalid
descriptions of the command line. The only other place this was used,
though, is when generating meson-log.txt.
Fix it to produce correctly formatted arguments.
Fixes #10980
|
|
The coverage report was always the final section of the main test run.
This made it hard to scroll around and find exactly what went wrong --
particularly as not everyone realizes that coverage isn't part of the
test run, but also because the output from coverage is... excessively
long.
This mirrors what we do in our other workflows.
|
|
clippy changed output message
fix #11004
|
|
|
|
Penalizing users for helping to test unstable modules really makes no
sense. As a fatal warning, users can no longer use
`--fatal-meson-warnings`.
|
|
The system linkers don't support this particular GNU extension on
these OS'es, so don't build them there.
Based on an OpenIndiana patch created by @alarcher. Closes #9882.
|
|
Apparently this is a misspelling even though it has been in the docs
since the creation of the module.
|
|
unescaped it's turned into a list item
|
|
The default actions one is broken in two ways, and additionally
overwrote homebrew's symlinks to begin with.
|
|
In a couple of python module tests, we try to test things that rely on
the default python being the same one we look up in the python module.
This is unsolvable for the deprecated python3 module, as it actually
uses the in-process version of python for everything. For the python
module, we could actually look up the default system python instead of
the one we are running with, but then we wouldn't be testing the
functionality of that alternative python... and also the install
manifest tests would see files installed for the wrong version of
python, and report a combination of missing+extra files...
Solve both tests by just skipping the parts we cannot check.
|
|
- minor cleanups in the vicinity
|
|
- qt5 -> qt6
- remove version information from when the Qt6 module was not a thing
- linked to dependency function
- highlight version information with *...* and placing it at the front of options or on new lines in text
- reformatted for shorter lines
|
|
|
|
PR #10826 adds a couple of missing installation tags for the GNOME
module, ensure we document these.
|
|
Original patch by Helmut Grohne.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023744
|
|
Original patch by Helmut Grohne.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023744
|
|
Fixes:
- Incorrect, redundant, or overabundant usage of "just"
- Missing punctuation
- Missing "the"
- Parenthesized text far from what it describes
There are some subjective changes, I hope those aren't controversial.
|
|
|
|
|
|
Use OptionOverrideProxy instead of pure options.
Closes #10393
|
|
|
|
|
|
We consistently use the "dependencies" kwarg to refer to C-like
CFLAGS/LDFLAGS interfaces. And for hotdoc, we actually accept libraries
for this as well, as we may want to document their (generated?) sources,
so we want their CFLAGS too.
But we also accepted custom targets and just added a build order
dependency on these, which was odd and typically we call that "depends".
Let's deprecate this in favor of the depends kwarg.
|
|
Internally we pass this as extra_depends to the CustomTarget
initializer, so it makes sense to call it that rather than confusing the
topic by referring to "dependencies", a term that indicates
CFLAGS/LDFLAGS interfaces.
|
|
mypy has a bug when running on/for 3.11 which results in incorrect
analysis of the codebase, specifically due to enum.Enum's self.name
See:
https://github.com/python/typeshed/issues/7564
https://github.com/python/mypy/issues/12483
|
|
|
|
|
|
|
|
|
|
|
|
I assume there's no real reason this cannot happen, perhaps if the meson
source directory has one. So we should use Popen_safe for safety
reasons.
|
|
We would like to use the default value (the one python urged us not to
use), but without getting a warning for it. Luckily, we have the correct
value already, so we can pass it manually to avoid the complaint.
|
|
python 3.11 adds a warning that in 3.15, UTF-8 mode will be default.
This is fantastic news, we'd love that. Less fantastic: this warning is
silly, we *want* these checks to be affected. Plus, the recommended
alternative API would (in addition to warning people when UTF-8 mode
removed the problem) also require using a minimum python version of 3.11
(in which the warning was added) or add verbose if/else soup.
The simple, and obvious, approach is to add a warnings filter to hide
it.
|
|
It is, after all, "safe". ;) That's why it exists. There's no reason to
think listing all pkg-config entries cannot print unicode descriptions,
it's absolutely possible, and we should handle it properly if we
encounter it.
|
|
|
|
It was only trying to guess install tag, and log missing tags, for files
installed by install_data(). Do it also for all other files, especially
custom_taget() that commonly installs generated headers.
|
|
|
|
This fix a crash when using NASM on Windows.
|
|
|
