When generating aggregated targets, custom targets were not being
checked for dependencies when they should have.
Fixes passing swift test case 4 (generate).
This must be explicitly set in Xcode or it will not be able to compile
mixed targets successfully. This is not needed for pure Swift targets.
Set a new variable "is_swift" so finding the bridging header does not
take O(n^2) time.
Fixes passing swift test case 5 (mixed) with Xcode backend.
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
Meson supports other transpilers generating source code for which
compilation rules need to be generated other than Vala. Reflect this
in variable names and comments to avoid confusion.
Currently in cross-compilation mode the --host is set to x86-linux-linux,
which results in an error.
Change the code so that for x86 and x86_64 the second part is 'pc',
and 'unknown' for the rest.
Use cpu model instead of cpu family for the first part, as suggested
by @dcbaker
As the result, we get: i386-pc-linux on my setup.
Fixes#12608
This commit modifies the get_target_filename_for_linking function to
always return POSIX-style paths, even on Windows systems. This is
necessary because the Ninja generator can have issues with Windows-style
paths when using the `/WHOLEARCHIVE:` flag.
This is consistent with the syntax accepted by the cl and clang-cl
compilers, as documented in the Microsoft documentation:
https: //learn.microsoft.com/en-us/cpp/build/reference/cl-filename-syntax?view=msvc-170
Fixes: 12534
Version 2.0 of lcov triggers an error when an exclude pattern is unused. This
can happen when the project has subprojects, but no code in them ends up
covered:
lcov: ERROR: 'exclude' pattern '/[...]/subprojects/*' is unused.
(use "lcov --ignore-errors unused ..." to bypass this error)
So, simply do as it says. Unused patterns doesn't seem problematic (or even
interesting) here, so I don't think there's any risk in simply turning this
off, which matches what happened with earlier versions of lcov anyway.
Emitting -undefined,error was correct,, but starting with Xcode 15 / Sonoma,
doing so triggers "ld: warning: -undefined error is deprecated". Given that
"-undefined error" is documented to be the linker's default behaviour, this
warning seems ill advised. However, it does create a lot of noise. As
"-undefined error" is the default behaviour, the least bad way to deal with
this seems to be to just not emit anything. Of course that only works as long
as nothing else injects -undefined dynamic_lookup, or such. Complain to Apple.
Fixes: https://github.com/mesonbuild/meson/issues/12450
no_warn_args is unused. Its only purpose was to implement automatic
hiding of UB in transpiled code, and it was not used at all in languages
other than C/C++ -- specifically when the C/C++ source files were
created by transpiling from vala or cython.
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.
The new linker in Sonoma / Xcode 15 considers the dependency via the
initializer sufficient to pull in the library. The man page now notes:
The linker never dead strips initialization and termination routines.
They are considered "roots" of the dead strip graph.
I could not find a good way to skip only if the linker version is new
enough. Before long everyone will be using the new linker anyway...
This was encountered while looking into an issue with
https://github.com/NixOS/nixpkgs/pull/268583.
I run my Nix store on case-sensitive APFS, so the test fails due to
trying to link `-framework ldap` instead of `-framework LDAP`.
The code assumed that sysconfig.get_platform() returns "mingw" for mingw Python,
but that's no longer the case for 2.5 years now, as it now only starts with
"mingw" and contains further information like the arch and other ABI relevant things
to avoid conflicts.
This updates the detection code to the current status quo. mingw Python only documents
right now that it starts with "mingw", and none of that arch stuff, but it's
unlikely that this will change, and this looks less error prone than looking at CC.
Fixes#12547
Previously macos reported "ld: unknown option: --version" when being passed
--version, but now sometimes it reports in plural, albeit without an obvious
pattern when. To handle that, simply just check for the prefix without the :
Fixes: https://github.com/mesonbuild/meson/issues/12552
If an annotation could not be resolved, it's classified as a "missing
import" and our configuration ignored it:
```
Skipping analyzing "mesonbuild.backends": module is installed, but missing library stubs or py.typed marker
```
As far as mypy is concerned, this library may or may not exist, but it
doesn't have any typing information at all (may need to be installed
first).
We ignored this because of our docs/ and tools/ thirdparty dependencies,
but we really should not. It is trivial to install them, and then
enforce that this "just works".
By enforcing it, we also make sure typos get caught.
This is needed now that str.format() is not allowing it any more. It is
also more consistent with other objects that have that method as well,
such as build targets.
Fixes: #12406
Releases have been happening an average of once every 90 days for the
past two years (since 0.60.0). If we just look at releases since 1.0.0,
the average is over 100 days.
[why]
On Apple clang 15.0.0 linker (i.e. ld64 1015.7) giving the same rpath
multiple times raises a warning:
ld: warning: duplicate -rpath '/local/lib' ignored
This can frequently happen when linking several dependencies that all
have that rpath in e.g. pkgconfig.
[how]
Deduplicate all rpath arguments.
[note]
I'm not sure how the code handles --start/end-group, but for rpath that
should not make any difference as that is not bound to a group.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Whilst working on the Reproducible Builds effort, we noticed that
meson was generates .pkgconfig files that are not reproducible.
For example, here is neatvnc's pkgconfig file when built with HEAD^1:
Name: neatvnc
Description: A Neat VNC server library
Version: 0.7.0
-Requires.private: pixman-1, aml < 0.4.0, aml >= 0.3.0, zlib, libdrm, libturbojpeg, gnutls, nettle, hogweed, gmp, gbm, libavcodec, libavfilter, libavutil
+Requires.private: pixman-1, aml >= 0.3.0, aml < 0.4.0, zlib, libdrm, libturbojpeg, gnutls, nettle, hogweed, gmp, gbm, libavcodec, libavfilter, libavutil
Libs: -L${libdir} -lneatvnc
Libs.private: -lm
Cflags: -I${includedir}
This is, ultimately, due to iterating over the contents of a set within a
DefaultDict and can thus be fixed by sorting the output immediately prior to
generating the Requires.private string.
An alternative solution would be to place the sorted(…) call a few lines
down:
return ', '.join(sorted(result))
However, this changes the expected ordering of the entire line, and many users
may be unhappy with that (alternative) change as a result. By contrast, this
commit will only enforce an ordering when there are multiple version
requirements (eg. a lower and a higher version requirement, ie. a version
range). It will, additionally, order them with the lower part of the range
first.
This was originally filed (with a slightly different patch) by myself in
the the Debian bug tracker <https://bugs.debian.org/1056117>.
Signed-off-by: Chris Lamb <lamby@debian.org>
EmbedManifest seems to default to true, which creates a default manifest based
on other parameters (likewise defaults) and makes it impossible to supply your
own with CREATEPROCESS_MANIFEST_RESOURCE_ID. There is value to being able to do
this and no value to the default one, so this should be disabled.
* unity builds: correct integer ceiling division
* edge case failure with unity builds:
- static archive bar that gets installed, that links with another static
archive foo that does not get installed
- the number of files in static archive foo is divisible by unity_size
would yield an error with ninja:
ninja: error: 'subprojects/foo/src/libfoo.a.p/meson-generated_foo-unity1.cpp.o', needed by 'src/libbar.a', missing and no known rule to make it
* unity builds: test for build failure when #files is divisible by unity_size
It was previously impossible to do this:
```
dep.get_pkgconfig_variable(
'foo',
define_variable: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
since get_pkgconfig_variable mandated exactly two (if any) arguments.
However, you could do this:
```
dep.get_variable(
'foo',
pkgconfig_define: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
It would silently do the wrong thing, by defining "prefix" as
`/usr=datadir=/usr/share`, which might not "matter" if only datadir was
used in the "foo" variable as the unmodified value might be adequate.
The actual intention of anyone writing such a meson.build is that they
aren't sure whether the .pc file uses ${prefix} or ${datadir} (or which
one gets used, might have changed between versions of that .pc file,
even).
A recent refactor made this into a hard error, which broke some projects
that were doing this and inadvertently depending on some .pc file that
only used the second variable. (This was "fine" since the result was
essentially meaningful, and even resulted in behavior identical to the
intended behavior if both projects were installed into the same prefix
-- in which case there's nothing to remap.)
Re-allow this. There are two ways we could re-allow this:
- ignore it with a warning
- add a new feature to allow actually doing this
Since the use case which triggered this bug actually has a pretty good
reason to want to do this, it makes sense to add the new feature.
Fixes https://bugs.gentoo.org/916576
Fixes https://github.com/containers/bubblewrap/issues/609
Albert Tang
arch1t3cht
Eli Schwartz
Daniele Nicolodi
Stas Sergeev
Erwin Jansen
David Robillard
Andres Freund
Dylan Baker
Randy Eckenrode
Christoph Reiter
Jan200101
Will Toohey
Xavier Claessens
Bin Meng
Gerion Entrup
Filipe Laíns
Peter Harris
Alyssa Ross
Fini Jastrow
Chris Lamb
Tamás Bálint Misius
Jussi Pakkanen
David Seifert
albert
Marcel Telka