Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
googletest 1.12.1 generates new JUnit4 invalid attributes file and
line.
Maybe all gtest "invalid" attributes are actually valid JUnit5
attributes, and maybe schema should be upgraded to JUni5.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
|
|
This command is magical and I hate it. Mostly because it seems people
have no clue what it does, and what it doesn't do.
Provide informational messages to the user indicating how it works, e.g.
for debugging. Point out if we ran vsenv before shelling out to the
backend.
|
|
Because clang now defaults to a dwarf version that valgrind does not yet
support. There's support in valgrind git master, though.
|
|
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
|
|
fixes #10566
|
|
This is needed for 6.1 support as noted in commit
a606ce22eb0dd05eef56384d59954edad7da131d 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.
|
|
Add correct reading of pkgconfig-announced bindir and
pkgconfig-announced libexecdir. Will work only on 6.3+
|
|
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.
|
|
Use the same routines to handle output both when parsing the output and
when not. Also fixes broken stderr handling for parsed tests.
|
|
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.
|
|
In a bunch of places we need to list various types of libraries
including custom_target outputs, and it gets very long. Use a common
T.Union for this.
|
|
|
|
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.
|
|
Environment line may not contain '=' and thus fail to decompose into a
key/value pair.
|
|
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.
|
|
|
|
Not all "use -v" errors are Apple ld, and if it doesn't have better
output with -v instead of --version, we should not assume that is what
it is.
|
|
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.
|
|
Use join_args to ensure that commands are rendered correctly and with
less code.
|
|
follow standard variables and allow distributions to remove some entries from their cross-files
ex:
https://github.com/void-linux/void-packages/blob/f23acdd24bfade3a4e14809fafaffe09b3c3c318/common/build-style/meson.sh#L50-L54
variables chosen from the variables nixos sets
https://github.com/NixOS/nixpkgs/blob/ea0f14a502c60223c96066de3ed548cb3be8ca47/pkgs/build-support/bintools-wrapper/setup-hook.sh#L58
sorted alphabetically
|
|
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
|
|
Which is old and annoying and doesn't expose global symbols by default,
so we need a work around.
see: https://github.com/mesonbuild/meson/pull/10587
see: https://lists.gnu.org/archive/html/libtool/2002-07/msg00025.html
|
|
In commit 4ca9a16288f51cce99624a2ef595d879acdc02d8 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
|
|
work) based on host OS, not build OS.
|
|
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.
|
|
Use join_args to ensure that commands are rendered correctly.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
In Fortran and C++ all the bits we care about are in ASCII. 8-bit
characters can only occur in comments and string literals and we don't
parse those.
|
|
Change the order of testing flags and get_external_args() to
handle flags set by get_external_args() correctly.
|
|
Let people easily find the documentation for concepts we are trying to
teach.
|
|
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 6e7c3efa793c25259891d3b5471343f95fb061fa.
- Revert "Visual Studio: Only use /utf-8 on VS2015 or later or clang-cl"
This reverts commit 8ed151bbd786d2c52e6ea7b7cfe3147fc41ec041.
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.
|
|
This is only supported with gfortran, see "test cases/fortran/6 dynamic"
for more details. Skip it explicitly here too.
|