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.
(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
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.
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 removes one line of stderr output per GObject Introspection file
processed, e.g.
g-ir-scanner: link: gcc -o Fwupd-2.0 Fwupd-2.0.o -L. -Wl,-rpath...
This error message was quite confusing when triggered by
use of an absolute path to the include dir of an external dependency
(numpy in my case). Changing that to a relative dir also isn't
a solution, because Meson will *not* do the "busywork to make paths
work" that the error message says it will.
Transpilers need to run on the build machine in order to generate their
output, which can then be taken by a cross-compiler to create the final
output.
For the same reasons commit 7aa28456d ("Add dependency type for
Valgrind") removed linking with valgrind, pkgconfig shouldn't generate
"Requirements" for it, in general.
This solves dbus meson port question/issue from:
https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/303#note_1444819
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
MachineChoice is a mesonlib object, not a compilers object, so it makes
no sense to import it from the latter simply because the latter imports
it too. This results in brittle module dependencies and everything
breaking when a refactor removes it from the latter.
... also it is a typing-only import so while we are fixing it to import
from the right place, we can also put it in a type-checking block.
The old implementation assumed a path is of Windows iff the second
character is a colon. However, that is not always true.
First, a colon can be included in a non-Windows path. For example, it is
totally fine to have a directory named ':' on Linux 5.17.0 tmpfs.
Second, a Windows path may start with \\ for UNC or extended length.
Use pathlib to handle all of these cases.
Regardless of which MachineChoice we base the platform on, we compare
its value to lowercased identifiers. So we need to lowercase the
targetplatform too... but we only did so sometimes.
This broke e.g. on "Win32", but only when *not* doing a cross build.
Fixes#10539
We have to handle this, because Windows needs to link to the implib of
the executable (???) in order to create a shared module. This is
explicitly checked for and handled in the backend, and creating a build
target with `link_with: some_exe` still works, even. But updating
declare_dependency to typed_kwargs neglected to take that into account,
so creating a convenience interface for those same arguments failed.
In PR 10263, we didn't account for that we may have initialize the Visual
Studio-like compiler two times, once for a C compiler and once for the
C++ compiler, so we end up with Meson breaking on Visual Studio 2013
or earlier, such as when building GLib.
Fix this by setting up the always_args member of
the VisualStudioLikeCompiler instance during __init__() as needed, so that
we avoid falling into modifying shared objects.
In commit 3dcc712583 we moved to
typed_pos_args. In the process, we deleted some code to specifically
raise an error if you use custom_target or generator outputs, instead
leaving it out of the typed pos args.
However, that support was specifically supposed to be there. It was only
an error in part of an if statement for handling old versions of
glib-compile-resources. The specific error it calls out is that we need
to manually parse the depfile at configure time, due to an external bug;
obviously this is impossible if the gresource is only created at build
time.
Reinstate the original error message check, and allow built outputs to
be used as compile_resources() inputs.
Fixes#10367
The check for if the project supports the -j flag was needlessly
complex. We support two types of project:
- waf, always supports -j
- make, if GNU, supports -j
We never checked waf, and the make check assumed that the entire
command, rather than just the last component, was "make". It also
neglects "gmake".
Since any possible build command *may* support -j, always run the
--version check. Detect either build command in the output.
Eli Schwartz
Artturin
Daan De Meyer
Omer Pereg
Dylan Baker
Justin Blanchard
Volker Weißmann
Prathamesh
Ty
Nirbheek Chauhan
Jussi Pakkanen
Christian Wendt
David Seifert
Richard Hughes
Ralf Gommers
Tristan Partin
Marc-André Lureau
Akihiko Odaki
Tad Young
fxxf
Xavier Claessens
Chun-wei Fan
Olexa Bilaniuk
Staz M