Fixes regression from commit 78e9009ff9.
The above commit relied on rpath_dirs_to_remove being present and
correctly filled, which was never the case for the AppleDynamicLinker.
The result was that all the build-dir-only RPATHs were being carried
over to the installed files.
This commit implements returning the list of RPATHs to remove in
AppleDynamicLinker, doing pretty much the same thing as what's in the
GnuLikeDynamicLinkerMixin. Thanks to that, depfixer now correctly
removes build-time Meson-created RPATHs, as it used to before 1.4.1.
Cargo.lock is essentially identical to subprojects/*.wrap files. When a
(sub)project has a Cargo.lock file this allows automatic fallback for
its cargo dependencies.
Running `touch` on a tracked file in Git, to update its timestamp, and
then running `meson dist` would cause dist to fail:
ERROR: Repository has uncommitted changes that will not be included in the dist tarball
Use --allow-dirty to ignore the warning and proceed anyway
Unlike `git status` and `git diff`, `git diff-index` doesn't refresh the
index before comparing, so stat changes are assumed to imply content
changes. Run `git update-index -q --refresh` first to refresh the index.
Fixes: #12985
Since it's an implementation detail, and shouldn't be exposed. This also
helps give better error messages when a user writes `import('qt')`,
since otherwise you get an error about `qt doesn't have an initialize
method`, and now you get `qt module doesn't exist`.
This fixes issues where a new option is added, an option is removed, the
constraints of an option are changed, an option file is added where one
didn't previously exist, an option file is deleted, or it is renamed
between meson_options.txt and meson.options
There is one case that is known to not work, but it's probably a less
common case, which is setting options for an unconfigured subproject.
We could probably make that work in some cases, but I don't think it
makes sense to download a wrap during meson configure.
This demonstrates a limitation of Meson that can happen in the following
situation:
`meson setup builddir`
<update to meson.options> (such as git pull)
`meson configure -Dnew_option=value builddir`
<Error>
Since Meson is unaware of the updates to the meson.options file. The
purposes of these tests is to fix this behavior.
On Arch's shiny new 48-core/96-thread build server, the
`test_install_log_content` test fails because of an unexpected
`invalid-symlink.txt` file. Apparently the test runs in parallel with
`test_install_subdir_symlinks`, which modifies the `59 install subdir`
source directory.
To fix this, make `install_subdir_invalid_symlinks` copy the entire test
into a tmpdir before modifying it.
By adding the option name to UserOption object, it is now possible to
display the name of the affected option when the given option value is
not valid.
Fixes#12635
When only a single input file shows up in an arglist, it makes no sense
to inject `-W,--start-group -lone -Wl,--end-group`, since there is
nothing being grouped together. It's just longer command lines for
nothing.
For instance, on Windows, if the terminal is in cp65001, the subprocess
output is not encoded correctly and it results in error when running
unit test.
Python provides some nifty tools for mocking, without relying on
altering running code. We should use these to simplify the actual run
paths and move the complicated logic into tests.
Meson will implicit rpaths when *.so/*.dll/etc. files are injected onto
the link line from pkg-config and (now) cmake dependencies.
Extend the "prebuilt shared" tests to test that these are added.
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
The unit test infrastructure hardcodes the architecture as x86_64. On
macos, the test_pkgconfig_parse_libs() test creates a few libraries
for testing using clang. This leads to the test failing on arm based
macs, as darwin_get_object_archs() will skip over these libraries,
which then leads to the test failing because of using -l instead of
referencing the libraries by their full path.
I am not at all sure this is the best approach.
I am also somewhat confused why nobody else has encountered this? CI
apparently just runs on x86_64 macs?
CC: @tristan957
The former has rust dependencies, which lead to max capping on Cygwin
since there is no rust compiler there. But it turns out there are other
disadvantages of jsonschema:
- it involves installing 5 wheels, instead of just 1
- it is much slower
To give some perspective to the latter issue, this is what it looks like
when I test with jsonschema:
```
===== 1 passed, 509 deselected in 3.07s =====
Total time: 3.341 seconds
```
And here's what it looks like when I test with fastjsonschema:
```
===== 1 passed, 509 deselected, 1 warning in 0.28s =====
Total time: 0.550 seconds
```
I cannot think of a good reason to use the former. Although in order to
work on old CI images, we'll support it as a fallback mechanism
This was originally added for vala only, with the rationale that vala
generates bad code that has warnings. Unfortunately, the rationale was
fatally flawed. The compiler warns about a number of things, which the
user can control depending on their code (or their code generator's
code), but some of those things are absolutely critical to warn about.
In particular, GCC 14 and clang 17 are updating their defaults to warn
-- and error by default for -- invalid C code that breaks the standard,
but has been silently accepted for over 20 years "because lots of people
do it". The code in question is UB, and compilers will generate faulty
machine code that behaves erroneously and probably has a mass of CVEs
waiting to happen.
Compiler warnings are NOT safe to just... universally turn off. Compiler
warnings could be either:
- coding style lints
- threatening statements that the code is factually and behaviorally wrong
There is no magic bullet to ignore the former while respecting the
latter. And the very last thing we should ever do is pass `-w`, since
that causes ALL warnings to be disabled, even the manually added
`-Werror=XXX`.
If vala generated code creates warnings, then the vala compiler can
decrease the log level by generating better code, or by adding warning
suppression pragmas for *specific* issues, such as unused functions.
We try to backtrack through the filesystem to find the correct directory
to build in, and suggest this as a possible diagnostic. However, our
current heuristic relies on parsing the raw file with string matching to
see if it starts with `project(`, and this may or may not actually work.
Instead, do a bit of recursion and parse each candidate with mparser,
then check if the first node of *that* file is a project() function.
This makes us resilient to a common case: where the root meson.build is
entirely valid, but, the first line is a comment containing e.g. SPDX
license headers and a simple string comparison simply does not cut it.
Fixes the bad error message from #12441, which was supposed to provide
more guidance but did not.
This does require hacking up the test pretty badly, since we need to not
ever pass GCC these invalid values. But it's preferable to writing
another project test I think.
Co-Authored-by: Nirbheek Chauhan <nirbheek@centricular.com>
Which allow passing arguments specifically to the static or shared
libraries.
For design, this is all handled in the interpreter, by the build layer
the arguments are combined into the existing fields. This limits changes
required in the mid and backend layers
Since the previous commit allows for more scenarios with name
collisions, it makes sense to expand the compile command so that it can
also take into account suffixes. i.e. meson compile -C build foo.exe can
now work if the executable has an exe suffix along with being named foo.
When checking target names, meson explictly forbids having multiple
targets with the same name. This is good, but it is strict and it is
impossible to have targets with the same basename and differing suffixes
(e.g. foo and foo.bin) in the same directory. Allow this for executables
by including the suffix (if it exists) in the interal target id. So foo
would be foo@exe and foo.bin would be foo.bin@exe.
Piotr Brzeziński
Xavier Claessens
Jussi Pakkanen
Andrew McNulty
Wolfgang Walther
Stas Sergeev
Benjamin Gilbert
Tristan Partin
Dylan Baker
Charles Brunet
Jan Alexander Steffens (heftig)
Eli Schwartz
Jonathon Anderson
Alyssa Ross
Andres Freund
Benjamin Redelings
Dudemanguy