Since they do not implement a default install dir like BuildTargets do.
gnome.compile_resources() would result in an unhandled python exception
when missing install_dir argument together with providing following arguments:
gresource_bundle: true
install: true
closes: https://github.com/mesonbuild/meson/issues/13447
Signed-off-by: RaviRahar <ravirahar33@gmail.com>
For other reasons, Meson transforms "-Wno-x" into "-Wx -Wno-x" for GCC,
but this breaks with "-Wno-attributes=x" with:
```
cc1plus: error: arguments ignored for '-Wattributes='; use '-Wno-attributes=' instead
```
Suppress that workaround for -Wno-attributes=.
Closes: https://github.com/mesonbuild/meson/issues/13022
aee941559 ("rust: recursively pull proc-macro dependencies as well")
had to be reverted (in a66cb97e8) because it broke Mesa cross
compilation. This happened because a C shared library was linked with
a Rust C-ABI static library, which caused it to inherit the proc macro
dependency the Rust static library was linked with.
The right way to handle this is for only Rust targets to inherit proc
macro dependencies from static libraries they link with. A Rust
executable, library, or whatever will need the proc macros its Rust
dependencies use, as illustrated in the test case that I've
reintroduced here.
I've verified that Mesa still cross compiles correctly with this
change. The same failure was also identified by the "rust/21
transitive dependencies" test case, but only when cross compiling, so
it wasn't caught by CI.
Co-authored-by: Xavier Claessens <xavier.claessens@collabora.com>
If need_exe_wrapper() is called while figuring out the language compiler,
the MachineInfo isn't complete yet, so machine_info_can_run() would return
False despite not cross compiling.
Make sure this fails loudly.
c1076241af changed the logic in multiple
places, in particular it looks like it was assumed that is_cross is always
the same as need_exe_wrapper(), but that's not true.
Also the commit only talks about mypy, so this was definitely not intended.
This reverts all the cases where need_exe_wrapper() was introduced back to
is_cross.
The change in backends.py could be a correct simplification, but I don't know
the code base enough, so reverting that too.
See #13403 and #13410
This reverts commit cc201a5396.
It's true that some aarch64 CPUs can run 32-bit ARM code, but some
(especially high-end ones, those most likely to be running builds)
cannot. It's better to assume that they can't, so builds don't
unnecessarily fail due to attempting to run a sanity check executable.
CMake has two target properties, LINK_OPTIONS and INTERFACE_LINK_OPTIONS.
The former is for link flags that apply only to the target (PRIVATE).
The latter is used for link flags that propagate to dependents (PUBLIC
or INTERFACE). Meson currently propagates all flags, PUBLIC and PRIVATE,
as part of the generated dependency() which causes problems when some of
the private flags are highly disruptive, e.g. `-Wl,--version-script`.
Tease apart the two kinds of link flags and, for non-static libraries,
only propagate the PUBLIC/INTERFACE flags and not the PRIVATE ones.
The documentation for subprocess.run at https://docs.python.org/3/library/subprocess.html#popen-constructor has a warning,
pointing to using shutil.which() instead of subprocess.run for detecting if exe files exists on the path.
shutil.which() is used in many places already.
Fix incorrect map access to custom_target_output_buildfile in CustomTargetIndex
case. Map keys are file names with the path appended, but the used keys were
just the file name. This led to crashes.
Revert "interpreter: when overriding a dependency make its name match"
This reverts commit b1340e9bb1.
Revert "dependency: define equality and hash operators for Dependency"
This reverts commit 6d713e40f8.
This caused some projects to fail to build, such as libplacebo and
libepoxy. Taking libplacebo as the example, the produced build.ninja
does not include libvulkan.so as a linker input for
src/libplacebo.so.338.
We are probably getting dependency hashing wrong somewhere. Unsure where
exactly and unsure how to create a test case. We are also deep into rc2.
Revert it for now and try to re-land these changes for 1.6.
Bug: https://bugs.gentoo.org/935443Fixes: #13352
This reverts commit 9f02d0a3e5.
It turns out that this does introduce a behavioral change in existing
users of ConfigurationData, which it wasn't supposed to (it was supposed
to preserve behavior there, and add a new *warning* for
EnvironmentVariables).
This breaks projects such as pulseaudio, libvirt, and probably more.
Roll back the change and try again after 1.5.0 is released.
Fixes: #13372
Don't require the string to be enclosed in parentheses.
https://github.com/llvm/llvm-project/pull/97323 changed the LLD
version printout to no longer be enclosed in parentheses, which
made Meson fail to detect the linker style used here.
The LLD change is being reverted in
https://github.com/llvm/llvm-project/pull/97698 in order to fix
building with existing Meson versions, but for the future, loosen
the check slightly, to not require the parentheses.
When building a limited API module on Windows the library
to link with should be python3.dll, not python3X.dll. This was
already the case for non-GCC, but should have been the case
unconditionally.
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.
XCode project file contains dictionary-like structures. Strings for the
mapped values have to be quoted if these include special characters.
Previously this quoting was happening in-place, before adding a new
value to the dictionary. This produce big amounts of boilerplate
error-prone code. For example if there are targets whose names contain special
characters (grpc++ in my case), produced file will be invalid.
This moves checking and quoting subroutine to the PbxDictItem class,
eliminating the need to do this on the caller side.
[Kin](https://github.com/Serchinastico/Kin) tool was used to validate
produced PBXProj files.
Fixes regression in commit 78e9009ff9.
new_rpath is only set when install_rpath appears in meson.build.
Before this commit, we treated new_rpath as a single string to pass to
-add_rpath. This worked as long as new_rpath had a single rpath in it,
though for ELF we explicitly supported multiple rpaths separated with
":" (as binutils ld is quite happy with that too).
install_name_tool does not support paths with colons in it:
```
21:12 <awilfox> Load command 19 cmd LC_RPATH cmdsize 40 path /bar:/baz:/eli:/ldap (offset 12)
21:12 <awilfox> Load command 20 cmd LC_RPATH cmdsize 24 path /foo (offset 12)
21:14 <awilfox> so the result is: do not use colons
```
After commit 78e9009ff9, we simply ended
up with one load command for LC_RPATH per char in new_rpath, which was
wrong in every possible case.
What we actually need to do is pass every distinct rpath as a separate
`-add_rpath` argument, so we split it on the colons instead. We do the
same splitting to ensure proper diff'ability for ELF anyways...
Fixes#13355
It was probably done this way originally since we didn't have the
`fatal` keyword argument to avoid triggering the fatal-meson-warnings.
While we're here, replace the use of a `if bool` with an `else` on the
for loop.
In commit 2cb7350d16 we added a special
case for environment() objects to allow skipping `meson --internal exe`
overhead when /usr/bin/env exists and can be used to set environment
variables instead of using a pickled wrapper.
This special case assumed that environment is used for setting
variables, but it is also possible, albeit less common, to
append/prepend to them, in which case `meson --internal exe` will
compute the final value as an offset from whatever the current environment
variables inherited from ninja are. It is not possible to precompute
this when generating command lines for ninja, so using arguments to
/usr/bin/env is not possible. All it can do is set (override) an
environment variable.
In this case, we have to use the python wrapper and cannot optimize it
away. Add a tracking bit to the env object and propagate it to the
backend.
_get_gnu_compiler_defines and _get_clang_compiler_defines were broken
by not defining the language they used.
Neither GCC nor Clang infer the language based on the driver name which means
`self.defines` isn't populated correctly in compilers/cpp.py.
e.g.
```
$ echo "" | g++ -E -dM - | grep -i cplus
$ echo "" | g++ -x c++ -E -dM - | grep -i cplus
#define __cplusplus 201703L
```
Fix that by passing '-cpp -x LANGUAGE' as a first pass. If it fails, try
again without '-cpp -x LANGUAGE' as before, as its portability isn't
certain. We do '-cpp' because during testing, I found Fortran needs this,
although per below, I had to drop Fortran in the end and leave it to the
fallback (existing) path.
Without this change, a63739d394 is only
partially effective. It works if the system has injected Clang options
via /etc/clang configuration files, but not by e.g. patching the driver
(or for GCC there too).
Unfortunately, we have to wimp out for Fortran and fallback to the
old method because you need the language standard (e.g. -x f95).
RaviRahar
Sam James
Alyssa Ross
Jussi Pakkanen
Christoph Reiter
Jonathon Anderson
Andreas Kässens
Zhipeng Xue
Mads Andreasen
Randy Eckenrode
Cepsylon
Andres Freund
L. E. Segovia
Eli Schwartz
Martin Storsjö
Andrew McNulty
Piotr Brzeziński
Mykola Dolhyi
Dylan Baker
Charles Brunet