The pkgconfig file in Debian and Ubuntu is definitely broken and we've
reported it upstream, but we don't really want to keep our image building
failing while we wait for that to be fixed.
Skip the auto/pkgconfig test if both: a) we're on Ubuntu, and b) the .pc
checksum matches a known-bad copy. I'm also CC'd to the bug to catch if it
gets fixed.
Bug: https://bugs.debian.org/1078026
for test attributes that are class constant. This reduces the work that
must be done for each test case, allowing some of the setup work to be
done once for the entire class.
Meson accidentally strips '-isystem' from C build args like ['-isystem',
'/path/to/headers'] if the compiler includes the current working directory
in the header search paths. The root cause is that '-isystem'[8:] evaluates
to an empty string and os.path.realpath('') returns the absolute path to
the current working directory, causing meson to think that '-isystem'
specifies a default include path.
Different compiler versions varies whether the current working directory is
in its search paths. For example, on Ubuntu 21.04:
# gcc -xc -v -E -
gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1)
#include "..." search starts here:
#include <...> search starts here:
.
/usr/lib/gcc/x86_64-linux-gnu/10/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
While on Ubuntu 24.04:
# gcc -xc -v -E -
gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu4)
...
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/13/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
Do not check the '-isystem=' and '-isystem/path/to/header' cases when the
option is '-isystem' but the path that follows is not a default search
path.
Signed-off-by: Junjie Mao <junjie.mao@hotmail.com>
This fixes a pesky failure in vs2019 vc2019x64ninja for d/11 dub:
```
Searching in DUB cache for compatible urld.lib
WARNING: No such cache folder: C:\Users\VssAdministrator\AppData\Local\dub\packages\urld-2.1.1\urld\.dub\build
ERROR: urld@2.1.1 not found
You may try the following command to install the necessary DUB libraries:
dub run --yes dub-build-deep -- urld --arch=x86_64 --compiler=dmd --build=debug
Run-time dependency urld found: NO
test cases\d\11 dub\meson.build:13:11: ERROR: Dependency "urld" not found
```
Follow dub's advice by installing urld in ci/run.ps1 before the testsuite;
we were already doing this for ubuntu, opensuse, and even recommending
it in our docs before now:
* ci/ciimage/ubuntu-rolling/install.sh
* ci/ciimage/opensuse/install.sh
* docs/markdown/Dependencies.md
We also bump to 'ci4' which has newer D added (from the cidata repo).
- check version of DUB for compatibility with Meson
- use "cacheArtifactPath" to locate DUB libraries in the cache
- propose `dub build --deep` command to Meson users for missing DUB
packages
Depending on DUB version, it will look either in the old cache structure
or use this new `dub describe` entry.
Updating the log message generated when installing a symbolic link. The
new message format may be a bit more clear on the link being created.
Signed-off-by: James Knight <james.d.knight@live.com>
Test '230 external project' uses make, but is too dumb to use the
platform conventions for shared library names in installed files
expected by shared_lib, so special case that.
By default, we build with debug info which can be useful for
investigating why a test segfaults instead of either passing or failing.
The nasm language hooks this up, but using nasm as a generator program
does not.
Bug: https://bugs.gentoo.org/936911
The command we use to heuristically parse whether it is dirty by
interpreting prose descriptions of the repository state, is vulnerable
to changes in locale resulting in failing to match the English word that
means it is clean.
Unfortunately, I am no mercurial expert so I am unaware if mercurial
supports scripting, like git does. Perhaps the technology simply does
not exist. A quick attempt at searching for the answer turned nothing
up. It appears that #4278 had good cause indeed for using this prose
parsing command.
So, we simply sanitize the environment due to lack of any better idea.
Bug: https://bugs.gentoo.org/936670
In particular, it is only ever constructed once, and all but two of its
arguments are always passed. So there's no reason or valid justification
to initialize them as None or pretend that you have to check them for
None values. Nor in fact does the command list need to be a
default_factory.
There are also two instance attributes which it is never instantiated
with, but which are tracked after the fact. Don't add this to the
signature for `__init__` as that is misleading.
create_target_linker_introspection is only ever called from one place,
which passes in CompilerArgs. This was implemented in commit
5eb55075ba which performed this conversion
as a preventative measure, since its type was not obvious (and thereby
modified the *type* of the variable in place).
We have a function that wraps two others because it first checks whether
the input is static or shared. By the same token, it has to return types
valid for either. We already *know* that we are a shared library, so we
can and should use the real function directly, which is both a
micro-optimization of function call overhead, and fixes a mypy
"union-attr" error.
It's always true because the func is always a real, truthy func object.
In the cmake case, the logic seems to be broken because if a path is not
a file, then that includes the case where it does not exist. It also
clearly meant "or" instead of "and".
What actually ended up happening was that this check never fired at all.
Because "if not func and not ..." would always fail, because "not func"
is always false. Maybe we don't need this logic at all...
Sam James
Xavier Claessens
Dylan Baker
Junjie Mao
Dmitry V. Levin
Benoit Pierre
Jonathan Schleifer
Kacper Michajłow
Remi Thebault
Eli Schwartz
andy5995
Marvin Scholz
Sertonix
Jussi Pakkanen
James Knight
Jon Turney
Charles Brunet
Nirbheek Chauhan
H. Vetinari