Anywhere we have that, we also have the Environment object, which is
just wrapped by the Interpreter methods anyway. This avoids inderections
that are unnecessary.
We're getting errors that we don't care about on the CI like:
```
==> Pouring node@18--18.19.0.monterey.bottle.tar.gz
The formula built, but is not symlinked into /usr/local
Error: The `brew link` step did not complete successfully
Could not symlink lib/node_modules/npm/docs/content/commands/npm-sbom.md
Target /usr/local/lib/node_modules/npm/docs/content/commands/npm-sbom.md
already exists. You may want to remove it:
rm '/usr/local/lib/node_modules/npm/docs/content/commands/npm-sbom.md'
```
We don't care about node, the only reason it's getting updated is
because it's already installed on the image and brew is auto-updating
it. So let's disable auto-update.
This should have been done in my earlier fix, but kinda forgot to test and
fix it there as well.
See https://github.com/mesonbuild/meson/pull/11733 for the discussion.
Fixes: 8284be813 ("dependencies/llvm: strip default include dirs")
Signed-off-by: Karol Herbst <kherbst@redhat.com>
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
This properly sets the project version in projects meson generates from
cmake projects. This allows dependency fallbacks to properly check the
version constraints in dependency calls when falling back to a cmake
subproject. Before this would fail, because the project version was
undefined.
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
mypy will complain if backends.Backend has a lru_cache wrapped method,
but it is overridden in XCodeBackend with a method that isn't cached.
This is almost certainly a sign that we should be caching it here too
anyway. The generic backend cache was added years ago via an
intimidating commit f39d2cc3bf which
claims that it reduced call time from 60s to 0.000435s and that this was
specifically due to getting a coredata option every single time. This is
probably workload dependent, but getting an option is *not* nearly as
cheap as a throwaway function call.
Xcode does not recognize our private directories, nor does it ever
try to generate them. Instead, just import the build directories
for each swift dependency.
This fixes linking between swift targets when they are in their own
subdirectories, as they will have different build directories in that
case.
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
Dylan Baker
Charles Brunet
Nirbheek Chauhan
Karol Herbst
Michael Gene Brockus (Dreamer)
Alyssa Ross
Vincent Torri
Nicolas Werner
Andres Freund
H. Vetinari
Eli Schwartz
Albert Tang
arch1t3cht
Daniele Nicolodi
Stas Sergeev
Erwin Jansen
David Robillard
Randy Eckenrode
Christoph Reiter