In order to reliably link to static libraries or individual object
files, we need to take their languages into account as well. For static
libraries this is easy: we just add the static library's list of
compilers to the build target. For extracted objects, we need to only
add the ones for the objects we use.
But we did this really inefficiently -- in fact, downright terribly. We
iterated over all source files from the extracted objects, then tried to
look up a new compiler for them. Even though the extracted objects
already had a list of compilers! This broke once compilers were made
per-subproject, because while the extracted objects have a reference to
all the compilers it needs (just like static archives do, actually) we
might not actually be able to look up that compiler from scratch inside
the current subproject.
Fix this by asking the extracted objects to categorize all its own
sources and return the compilers we want.
Fixes#10579
This is needed for 6.1 support as noted in commit
a606ce22eb but at the time there was no
pkg-config detection method at all. The stub code for Qt6 didn't support
libexecdir at all, and the pkg-config files added to newer versions of
Qt6 didn't export that information either until a further bugfix release.
Enforce that this information is required.
After a recent CI image builder update successfully ran the tests, but
didn't run the cross tests, it updated the image that then got used by
the regular CI cross tests. Somehow this resulted in a bunch of tests
now failing because zlib could not be picked up. We probably dropped a
transitive dependency somewhere. Anyway, it's correct to explicitly
specify it if we need it.
Currently we invoke it with lang_args only, which is wrong and probably
useless.
Fixes misdetecting the linker when overridden as -fuse-ld, which led to
Meson trying to pass incompatible flags, outright failing if CFLAGS
contained flags that only work with a non-default linker, or in the most
benevolent case, having the status log report the wrong linker.
We've never used it for anything, it was originally added for #3776 but
that never got finished so it's just a waste.
This also prevents successful regeneration of the build image, because
nim is not available for Ubuntu rolling. It's available in 20.04 and
22.10, but vanished in between for reasons best known to Ubuntu.
The Windows 2016 images have been deprecated for a while now and
regularly browning out. There's no viable replacement for testing that
we can generate a usable `--backend=vs2017` project, so we cannot
migrate this to anything else.
The deprecated images are finally fully removed. See
https://github.com/actions/virtual-environments/issues/5403
And now we get universal red CI, we cannot just wait for the brownout to
end to get a tiny little bit of final testing.
Simply remove the jobs so that we can tell if all the CI that actually
runs, is passing.
Although the former accepts multiple awaitables, it is only ever called
with a single one, so just use `wait_for` instead.
Additionally, the `try_wait_one` fails in Python 3.11, as
`Process.wait()` returns a coroutine, and `asyncio.wait` only accepts
tasks, so it errors out.
We do something similar when running get_compiler() method checks from
the DSL. This ensures that if errors happen, the log file we tell people
to check actually works.
Currently, if we run "meson configure -Doption=value", meson will
do a reconfigure when running "ninja build" afterwards, even if
the new value is the same one that was already configured previously.
To avoid this unnecessary reconfigure, let's use replace_if_different()
instead of unconditionally replacing the conf file in coredata's save()
function.
custom_target allows selective installation if it outputs more than one
file. Mention this explicitly in install.
Additionally, fix the types for install_dir.
see: https://github.com/mesonbuild/meson/issues/505
(b, name) will always have the canonical tool name, not just a
potentially weird bin path. We need to check stderr for qt4 tools other
than lrelease, but we keyed off of the tool bin path, so matches were by
no means guaranteed, and specifically, would fail if the tool is looked
up via bindir.
This really should always have checked the canonical name, which is
guaranteed to be correct.
Partial fix for #10443
This forces the use of the Apple archiver, since that archiver doesn't
add extern'd variables to the symbol table automatically, and instead
requires that ranlib be used. A native file is used to ensure that
Apple's ar is used even in the presence of llvm or gcc in the path with
their superior archivers.
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
Apple's AR is old, and doesn't add externed symbols to the symbol table,
instead relying on the user calling ranlib with -c. We need to do that
for the user
In commit 4ca9a16288 we added unreliable
support (it warns you if you try it) for gcc-compatible treatment of
uppercase-C files being C++ instead of C. In order to handle it
correctly, we needed to evaluate can-compile by special-casing "C" to
avoid lowercasing it for comparisons.
This didn't cover all cases where we check if "C" is a C++ language
file. We also straight-up check the language of a file (rather than
working backwards to see if a C++ compiler can compile it) when doing
module scanning, and this needs to special-case "C" as well.
We also had one case where we only checked lowercase fortran extensions,
but not lowercase C++ extensions. While we are at it, use lowercase for
C++ as well, except the "C" special case.
Fixes#10629
If this command fails, for example when CXX is something not generic
enough to be a valid universal compiler command (clang -std=c++11
perhaps), we end up with two problems:
- it's impossible to figure out what Meson ran to get that error
- the error report isn't clear on what is stdout and what is stderr, or
even that that is what the message is about.
```
meson.build:1:0: ERROR: Unable to get clang pre-processor defines:
error: invalid argument '-std=c++11' not allowed with 'C'
```
What's C doing there and why is Meson talking about it? Answer: that's
compiler stdout. Say so.
We do something similar when running get_compiler() method checks from
the DSL. This ensures that if errors happen, the log file we tell people
to check actually works.
Ninja backend will fail to find the vs dep dependency
prefix string in a mingw64 environment. This change
simply updates the regex to be able to capture mingw64's unique
file separation pattern.
When `self.wrap.filesdir` is a relative path, which happens when
`meson subprojects update` is run, the path to the patch must be
provided relative to the working directory in which `patch` or `git`
is run.
`self.wrap.filesdir` is absolute when `Resolve()` is invoked by the
Meson interpreter, which is why this wasn't detected by the tests.
It saves bandwidth and disk usage on downloaded subprojects, and people
very rarely need more than the single commit they’re using.
Add `depth=1` to the `[wrap-git]` examples in the rest of the
documentation, to make it more likely that people will copy-and-paste it
into their `.wrap` files.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Specifically, this is a combination of the following:
- Revert "visualstudio.py: Apply /utf-8 only on clang or VS2015+"
This reverts commit 6e7c3efa79.
- Revert "Visual Studio: Only use /utf-8 on VS2015 or later or clang-cl"
This reverts commit 8ed151bbd7.
The changes were broken and untested, although this is because of a lack
of general CI testing for all languages on Windows. At least, this broke
the use of ifort, and possibly more.
The changes are fundamentally a bit "exciting", as they step out of the
hierarchy of compiler definitions and apply arguments almost willy-nilly.
And apparently it's leaky all over the place. I don't understand all of
what is going on with it, but it plainly failed to achieve its desired
goal and needs to be rolled back ASAP.
This enables the fortran tests for Azure.
We only test on x64, because:
- ifort isn't arm64 compatible
- x86 may in theory exist, but Meson reports it cannot compile
executables
These checked that e.g. the cpp and fc ids are identical, which isn't
strictly what we want. Particularly, msvc doesn't even have a fortran
compiler, and what we really care about is whether we mix both gcc and
something else.
Eli Schwartz
Daniel Mensinger
Konstantin
Hemmo Nieminen
Denis Fortin
Elliott Sales de Andrade
Zhangyuan Nie
Artturin
Daan De Meyer
Gerion Entrup
Omer Pereg
Ailin Nemui
Dylan Baker
Justin Blanchard
Volker Weißmann
Prathamesh
Ty
Nirbheek Chauhan
Jussi Pakkanen
Christian Wendt
Philip Withnall
Michael Davidsaver
Amit D