| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
GCC does not support constructor_priority on macos. It's possibly not the only
platform for which that is the case, but...
|
|
The path tested prior does not exist anymore in Sonoma. It seems less likely
that 'cat' will be removed, so use that.
|
|
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
|
|
This caused a regression with mesondefine where
`conf_data.set("FOO", true)`
turned into
`#define FOO 1`
instead of
`#define FOO`
|
|
I'm not 100% sure that warning is the appropriate action, but it's
better than failing with a backtrace.
Fixes: #12555
|
|
This allows mypy and pyright to correctly determine the return types
from methods, but makes 0 changes at runtime.
|
|
|
|
|
|
|
|
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.
|
|
For some reasons, with msys2 it sometimes raises OSError instead of
BrokenPipeError.
Fixes: #12541
|
|
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
|
|
Change the shell prompt to '#' to when installing as root.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
|
|
|
|
Signed-off-by: Filipe Laíns <lains@riseup.net>
|
|
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.
|
|
> error: unsupported option '--target'; did you mean '-target'?
|
|
[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>
|
|
"meson wrap status" was calling it for each .wrap file. Better use
lru_cache to ensure we don't make the same mistake elsewhere.
|
|
Update command is implemented in msubprojects.py, because it can update
all wraps in parallel.
|
|
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
|
|
|
|
|
|
|
|
This time we have a case where people are passing non-objects by using
them as str | File, which we never warned about and silently accepted.
If it was passed via custom_target outputs we *would* error out,
interestingly enough. At the backend layer, we just pass them directly
to the linker... which is valid, if we misdetected what's a valid linker
input or people just used funny names. In particular, the mingw
toolchain allows passing a *.def file directly, and some people are
doing that.
If we do want to allow this, we should do it consistently. For now, just
follow the current theme of what's expected, but do so by warning
instead of fatally erroring, for cases where users were able to do it in
the past.
|
|
In the case r1 -> s1 -> s2 where s1 and s2 are uninstalled C static
libraries, the libs1.a rule does not depend on libs2.a. That means that
r1 rule must depend on both s1 and s2.
|
|
|
|
We haven't actually verified that these kwargs are equal to what we had
before, and should probably revert the entire series. But I have
multiple reports in the wild of projects that no longer build because of
`install: [true, false, get_option('foobar')]` which was always
incorrect and always equal to just dropping values all over the floor
and treating it the same as "bool(value) == True".
Special case this particular typed kwarg and allow it with a sternly
worded warning that it was always wrong and should never ever ever be
done.
Fixes: https://bugs.gentoo.org/917118
Fixes: http://qa-logs.debian.net/2023/11/11/rhythmbox_3.4.7-1_unstable_meson-exp.log
Thanks to the Gentoo Tinderbox project, and Lucas Nussbaum of the Debian
project.
|
|
|
|
|
|
rust: Fix linking with C libraries in subdir
|
|
It is already done by RealPathAction and mypy started complaining about
it.
|
|
Fixes: #12494
|
|
CompilerArgs would otherwise dedup and reorder them.
|
|
Pass link arguments directly down to linker by using `-C link-args=`
instead of letting rustc/linker resolve `-l` arguments. This solves
problems with e.g. +verbatim not being portable. Note that we also pass
`-l` args as `-Clink-args=-l` because rustc would otherwise reorder
arguments and put `-lstdc++` before `-Clink-args=libfoo++.a`.
However, when building a rlib/staticlib we should still use `-l`
arguments because that allows rustc to bundle static libraries we
link-whole. In that case, since there is no platform specific dynamic
linker, +verbatim works.
This also fix installed staticlib that now bundle uninstalled static
libraries it links to (recursively). This is done by putting them all
into self.link_whole_targets instead of putting their objects into
self.objects, and let rustc do the bundling. This has the extra
advantage that rustc can bundle static libries built with CustomTarget.
Disable bundling in all other cases, otherwise we could end up with
duplicated objects in static libraries, in diamond dependency graph
case.
Fixes: #12484
|
|
CustomTarget and CustomTargetIndex often have to be special cased
because they are not subclass of BuildTarget. It's easier to introduce a
dummy base class.
This fix recursive functions over link targets that might encouters
libraries built as CustomTarget.
|
|
|
|
|
|
|
