Otherwise a wrapper script which takes an executable as an argument will
mistakenly run when that executable is cross compiled. This does not
wrap said executable in an exe_wrapper, just skip it.
Fixes#5982
If an executable is passed as an argument to a script in the build
directory that it resides in then it will not execute (on *nix) due to a
lack of ./. Ie, `foo` must be called as `./foo`. If it is called from a
different directory it will work. Ie `../foo` or `bar/foo`.
Fixes#5984
Gtest can output junit results with a command line switch. We can parse
this to get more detailed results than the returncode, and put those in
our own Junit output. We basically just throw away the top level
'testsuites' object, then fixup the names of the tests, and shove that
into our junit.
If the feature hadn't been broken in the first place it would have
worked on them anyway, so we might as well expose it. I'm loathe to do
it because one of the best features of meson in a mixed C/C++ code base
is that meson figures out the right linker every time, but there are
cases people have where they want to force a linker. We'll let them keep
the pieces.
JUnit is pretty ubiquitous, lots of services and results viewers
understand it, in particular gitlab and jenkins know how to consume
JUnit xml. This means projects using CI services can have their test
results consumed automatically.
Fixes: #6972
A current rather untyped storage of options is one of the things that
contributes to the options code being so complex. This takes a small
step in synching down by storing the compiler options in dicts per
language.
Future work might be replacing the langauge strings with an enum, and
defaultdict with a custom struct, just like `PerMachine` and
`MachineChoice`.
This does a couple of nice things, one is that editors like vscode can
be configured to use this schema to provide auto completion and error
highlighting if invalid values are added or required values are missing.
It also allows us test that the format of the test matrix work in a unit
test, which I've added. It does require that the python jsonschema
package is installed.
It can happen that a server is temporaly down, tarballs often have
many mirrors available so we should be able to add at least one fallback
mirror in wrap files.
* cmake: enhance support of cmake config file syntax
Enhance the cmakedefine support by accepting 2 or 3 tokens
in the conf line as mesondefine supports strictly 2 tokens
* fixup! cmake: enhance support of cmake config file syntax
* fixup! fixup! cmake: enhance support of cmake config file syntax
PR #6363 made it so our interpretation of env vars no longer clashed
with Autoconf's: if both Meson and Autoconf would read and env var, both
would do the same things with the value they read.
However, there were still cases that autoconf would read an env var when
meson wouldn't:
- Autoconf would use `CC` in cross builds too
- Autoconf would use `CC_FOR_BUILD` in native builds too.
There's no reason Meson can't also do this--if native cross files
overwrite rather than replace env vars, cross files can also overwrite
rather than replace env vars.
Because variables like `CC` are so ubiquitous, and because ignoring them
in cross builds just makes those builds liable to break (and things more
complicated in general), we bring Meson's behavior in line with
Autoconf's.
A couple used checks for specific compiler binaries, but those might not
be accurate for cross compiling. All the languages other than C and C++
(which we basically always assume we have) should have a
skip_if_not_lang check.
It may not be obvious to users that these two ways to set build-types
override each other and specifying both is redundant, and conflicts
are resolved based on whichever is specified later.
Closes https://github.com/mesonbuild/meson/issues/6742
With the current logic passing `--debug` will actually be parsed as
`-Ddebug=false`, which is absolutely not what is expected.
There is no case in which the presence of a boolean option in `--foo`
form will mean 'I want feature foo disabled', regardless of the
*default* value of that option.
Also includes a test.
Closes https://github.com/mesonbuild/meson/issues/4686
The previous code was assuming that options do not depend on each
other, and that you can set defaults using `dict.setdefault()`. This
is not true for `buildtype` + `optimization`/`debug`, so we add
defaults + overrides in the right order and use the options parsing
code later to compute the values.
Includes a test.
Closes https://github.com/mesonbuild/meson/issues/6752
Similar to meson.override_find_program() but overrides the result of the
dependency() function.
Also ensure that dependency() always returns the same result when
looking for the same dependency, this fixes cases where parts of the
project could be using a system library and other parts use the library
provided by a subproject.
This makes the typing annotations basically impossible to get right, but
if we only have one key then it's easy. Fortunately python provides
comprehensions, so we don't even need the ability to pass multiple keys,
we can just [extract_as_list(kwargs, c) for c in ('a', 'b', 'c')] and
get the same result.
listify shouldn't be unholdering, it's a function to turn scalar values
into lists, or flatten lists. Having a separate function is clearer,
easier to understand, and can be run recursively if necessary.
The old logic was completely broken, and didn't even assert that the
specified section was found at all. The CPU families test was broken
because of this. Luckily, the table didn't go out of sync with the
code.
It now also doesn't assume that each section has only one table. This
fixes the test now that we document the buildtype/optimization/debug
mapping in a second table inside the `Universal options` section.
* unittests: fix finding python2 if the binary is named python2
Because of the way the python module works the simplicity of the test
function is no longer valid, we need to have and additional name
parameter to make the python module work, as it doesn't look for an
entry called "python2" or "python3", only "python"
* unittests: Don't make our python 2.x check debian specific
* unittests: On macOS the python2 binary is still called python
This adds a warnings counter for subprojects that passed. This is to
encourage developpers to check warnings in the logs and hopefully fix
them. Otherwise they could be hidden in hundreds lines of logs.
This also print the error message for subprojects that did not pass. The
error message is often enough to fix the issue (e.g. missing
dependency) and it's easier than searching in the logs why a subproject
failed.
When a source file for a library is changed without adding new extern
symbols, only that library should be rebuilt. Nothing that uses it
should be relinked.
Along the way, also remove trailing `.` in all Ninja rule
descriptions. It's very confusing to see messages like:
```
Linking target mylib.dll.
```
It's confusing that the period at the end of that is not part of the
filename. Instead of removing that period manually in the tests (which
feels wrong!) just don't print it at all.
This makes two basic changes, 1 it moves the name of the linker into the
linker class, this should reduce the number of errors and typos, and
ensure that a linker always has one name. This then renames the linkers
to have more consistent names.
Posix/gnu linkers are called ld.<name>: ld.gold, ld.lld, ld.solaris.
Apple linkers are renamed ld64.
This allows users to disable writing out the inbuilt variables to
the pkg-config file as they might actualy not be required.
One reason to have this is for architecture-independent pkg-config
files in projects which also have architecture-dependent outputs.
For example : https://gitlab.freedesktop.org/wayland/weston/issues/269Fixes#4011
* Extend test_prefix_dependent_defaults unit test to cover default case
Extend test_prefix_dependent_defaults unit test to cover the default
case, when the default prefix is '/usr/local'. (On Windows, the default
prefix is 'c:/')
* Restore adjusting option defaults depending on the default prefix
Restore adjusting option defaults, depending on the default prefix.
Droppped in d778a371
Error is raised due to Elbrus Fortran compiler can't
generate debug information for now, because it's a 2-step
compiler where 1st step is code conversion from Fortran to C,
so debug information which C compiler would produce, is useless.
When a dependency is required, not found on the system, and its fallback
is disabled with --wrap-mode=nofallback, meson should abort instead of
returning not-found.
pkgconf automatically prunes "system library paths" from its output. The
system library paths depend on the system toolchain. A common value on a
64-bit system is as follows:
/lib64:/usr/lib64:/usr/local/lib64
So, if -L/usr/lib64 appears in the Libs section, it will be pruned from
the output of pkg-config --libs.
The pc files generated for this test contain something like this:
libdir=/usr/lib
Libs: -L${libdir} ...
pkgconf may not consider /usr/lib to be a system library path, so it is
not pruned as the test expects. To work around this, override the
compiled-in list of paths via the PKG_CONFIG_SYSTEM_LIBRARY_PATH
environment variable.
Fixes: https://github.com/mesonbuild/meson/issues/6004
The rust code is ugly, because rust is annoying. It doesn't invoke a
linker directly (unless that linker is link.exe or lld-link.exe),
instead it invokes the C compiler (gcc or clang usually) to do it's
linking. Meson doesn't have good abstractions for this, though we
probably should because some of the D compilers do the same thing.
Either that or we should just call the c compiler directly, like vala
does.
This changes the public interface for meson, which we don't do unless we
absolutely have to. In this case I think we need to do it. A fair number
of projects have already been using 'ld' in their cross/native files to
get the ld binary and call it directly in custom_targets or generators,
and we broke that. While we could hit this problem again names like
`c_ld` and `cpp_ld` are far less likely to cause collisions than `ld`.
Additionally this gives a way to set the linker on a per-compiler basis,
which is probably in itself very useful.
Fixes#6442
When there is more than one path in PKG_CONFIG_PATH. It is almost always
preferred to find things in the order specified by PKG_CONFIG_PATH
instead of assuming pkg-config returns flags in a meaningful order.
For example:
/usr/local/lib/libgtk-3.so.0
/usr/local/lib/pkgconfig/gtk+-3.0.pc
/usr/local/lib/libcanberra-gtk3.so
/usr/local/lib/pkgconfig/libcanberra-gtk3.pc
/home/mesonuser/.local/lib/libgtk-3.so.0
/home/mesonuser/.local/lib/pkgconfig/gtk+-3.0.pc
PKG_CONFIG_PATH="/home/mesonuser/.local/lib/pkgconfig:/usr/local/lib/pkgconfig"
libcanberra-gtk3 is a library which depends on gtk+-3.0. The dependency
is mentioned in the .pc file with 'Requires', so flags from gtk+-3.0 are
used in both dynamic and static linking.
Assume the user wants to compile an application which needs both
libcanberra-gtk3 and gtk+-3.0. The application depends on features added
in the latest version of gtk+-3.0, which can be found in the home
directory of the user but not in /usr/local. When meson asks pkg-config
for linker flags of libcanberra-gtk3, pkg-config picks
/usr/local/lib/pkgconfig/libcanberra-gtk3.pc and
/home/mesonuser/.local/lib/pkgconfig/gtk+-3.0.pc. Since these two
libraries come from different prefixes, there will be two -L arguments
in the output of pkg-config. If -L/usr/local/lib is put before
-L/home/mesonuser/.local/lib, meson will find both libraries in
/usr/local/lib instead of picking libgtk-3.so.0 from the home directory.
This can result in linking failure such as undefined references error
when meson decides to put linker arguments of libcanberra-gtk3 before
linker arguments of gtk+-3.0. When both /usr/local/lib/libgtk-3.so.0 and
/home/mesonuser/.local/lib/libgtk-3.so.0 are present on the command
line, the linker chooses the first one and ignores the second one. If
the application needs new symbols that are only available in the second
one, the linker will throw an error because of missing symbols.
To resolve the issue, we should reorder -L flags according to
PKG_CONFIG_PATH ourselves before using it to find the full path of
library files. This makes sure that we always follow the preferences of
users, without depending on the unreliable part of pkg-config output.
Fixes https://github.com/mesonbuild/meson/issues/4271.
There are two awful things about CompilerArgs, one is that it directly
inherits from list, and there are a lot of subtle gotcahs with
inheriting from builtin types. The second is that the class allows
arguments to be passed in whatever order. That's bad. This also fully
annotates the CompilerArgs class, so mypy can type check it for us.
This dumps xild on mac and linux. After a lot of reading and banging my
head I've discovered we (meson) don't care about xild, xild is only
useful if your invoke ld directly (not through icc/icpc) and you want to
do ipo/lto/wpo. Instead just make icc report what it's actually doing,
invoking ld or ld64 (for linux and mac respectively) directly. This
allows us to get -fuse-ld working on linux.
Previously if a user tried to pass a command line build
option that contained a '%' character the command line
parser assumed that there was string interpolation to be
done. As there is no sense in such a scenario no code
provides any input for the interpolation. This then leads to
a failure.
In this commit we specifically override the defaults in
ConfigParser and set interpolation to None, which disables
command line build option interpolation.
Fixes#6157
A build with a cross file should always be identified as a cross build, even if
the host and build machine are identical. This was the case in 0.50, regressed
in 0.51, and is fixed again in 0.52, so add a test case to ensure it doesn't
regress again.
Now that the linkers are split out of the compilers this enum is
only used to know what platform we're compiling for. Which is
what the MachineInfo class is for
test3-static was actually always using the shared library because that
warning was not fatal:
WARNING: Static library 'func6' not found for dependency 'func6', may
not be statically linked
The reason why the libfunc6.a wasn't found is because the prefix in the
generated pc file was not set to install dir.
In qemu, minikconf generates a depfile that meson could use to
automatically reconfigure on dependency change.
Note: someone clever can perhaps find a way to express this with a
ninja rule & depfile=. I didn't manage, so I wrote a simple depfile
parser.
According to http://testanything.org/tap-specification.html
"Any output line that is not a version, a plan, a test line, a
diagnostic or a bail out is considered an “unknown” line. A TAP parser
is required to not consider an unknown line as an error but may
optionally choose to capture said line and hand it to the test
harness, which may have custom behavior attached [...] TAP::Harness
reports TAP syntax errors at the end of a test run".
(glib gtest can generate empty lines)
The main library must come before extra libraries, because they are
likely to be dependencies of the main library that get promoted from
private to public. This was causing static link issues with glib-2.0.pc.
On illumos (and presumably Solaris, though I can't test) cc normally
points to Sun CC, which we don't support. So ensure that gcc is used
explicitly in that case.
* Do not strip static archives
Stripping static archives without more fine-grained options (e.g. `-g`)
leads to failures such as
ld: libfoo.a: error adding symbols: archive has no index; run ranlib to add one
because GNU strip removes *every* symbol in a static archive by default.
Given that static archives are not final build artifacts (unlike
executables and shared libraries), stripping them gains little and only
causes more edge case failures.
* Gentoo's portage only strips debug information:
86f211e3a5/bin/estrip (L322)
* Fedora also only strips debug information:
e9c13c6565/scripts/brp-strip-static-archive (L18)
* Debian also only does some very light stripping:
72ed1d3261/dh_strip (L374)Fixes#4138
* Add test case for static archive stripping
Instead of the DynamicLinker returning a hardcoded value like
`-Wl,-foo`, it now is passed a value that could be '-Wl,', or could be
something '-Xlinker='
This makes a few things cleaner, and will make it possible to fix using
clang (not clang-cl) on windows, where it invokes either link.exe or
lld-link.exe instead of a gnu-ld compatible linker.
Clang doesn't really like having no-undefined plus the address sanitizer, but
gcc doesn't mind. This all happens to work with clang + gnu ld, but with clang
+ apple ld this turns into a dumpster fire. Just add b_lundef=false to make
everyone happy.
@TingPing has a repository that contains a grammar for meson which is
used by linguist (GitHub), and by many editors such as Atom, VS Code,
TextMate, Sublime Text, etc. Add CI so that we notice that the
function list in it is out of date, such as https://github.com/TingPing/language-meson/pull/3
It's harder to do this generically for other syntax such as the `in`
keyword, but it's better than nothing.
This reverts the changes to the `section` key for the
buildoptions and moves the machine choice into it's
own `machine` key.
With this commit the __undocumented__ breaking change
to the introspection format (introduced in 0.51.0) is
reverted and a new key is added instead.
Instead of trying to guess whether we need py or python3, and then
falling over when whatever we guessed isn't in the path or isn't right,
just use sys.executable which should always work.
* coredata: Correctly handle receiving a pipe for native/cross files
In some cases a cross/native file may be a pipe, such as when using bash
process replacement `meson --native-file
<([binaries]llvm-config='/opt/bin/llvm-config')`, for example. In this
case we copy the contents of the pipe into a file in the meson-private
directory so we can create a proper ninja dependency, and be able to
reload the file on --wipe/--reconfigure. This requires some extra
negotiation to preserve these native/cross files.
Fixes#5505
* run_unitests: Add a unit test for native files that are pipes
Using mkfifo.
We were setting the base options for the Objective-C compiler
manually, due to which options such as b_bitcode and b_ndebug were not
getting set at all.
The base options here are the same as for C code with the Clang
compiler, so just use the same inherited list.
Also expand the bitcode test to ObjC and ObjC++ so this doesn't happen
again.
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
It was using ':' as a path separator while GCC uses ';' resulting in bogus
paths being returned. Instead assume that the compiler uses the platform native
separator.
The previous splitting code still worked sometimes because splitting
"C:/foo;C:/bar" resulted in the last part "/bar" being valid if "<DriveOfCWD>:/bar"
existed.
The fix also exposes a clang Windows bug where it uses the wrong separator:
https://reviews.llvm.org/D61121 . Use a regex to fix those first.
This resulted in linker errors when statically linking against a library which
had an external dependency linking against system libs.
Fixes#5386
Currently this test assumes that the user doesn't have XDG_DATA_HOME
set in their path, but this isn't a good assumption, and can result in
the test not actually testing what it means to.
Meson itself *almost* only cares about the build and host platforms. The
exception is it takes a `target_machine` in the cross file and exposes
it to the user; but it doesn't do anything else with it. It's therefore
overkill to put target in `PerMachine` and `MachineChoice`. Instead, we
make a `PerThreeMachine` only for the machine infos.
Additionally fix a few other things that were bugging me in the process:
- Get rid of `MachineInfos` class. Since `envconfig.py` was created, it
has no methods that couldn't just got on `PerMachine`
- Make `default_missing` and `miss_defaulting` work functionally. That
means we can just locally bind rather than bind as class vars the
"unfrozen" configuration. This helps prevent bugs where one forgets
to freeze a configuration.
The Intel compiler is strange. On Linux and macOS it's called ICC, and
it tries to mostly behave like gcc/clang. On Windows it's called ICL,
and tries to behave like MSVC. This makes the code that's used to
implement ICC support useless for supporting ICL, because their command
line interfaces are completely different.
pkg-config(1) on OpenBSD is not the one from freedesktop.org and hence has
subtle differences (which don't impact real usage). The meson test fails
because white space between operators are stripped by our pkg-config:
$ grep Require /usr/local/lib/pkgconfig/xmlsec1.pc
Requires: libxml-2.0 >= 2.8.0 libxslt >= 1.0.20
$ pkg-config --print-requires xmlsec1
libxml-2.0>=2.8.0
libxslt>=1.0.20
There actually is an ICC for windows that can be used to cross compile
from Windows to Linux, but it's not supported in meson currently and I
don't plan to enable it.
Currently C++ inherits C, which can lead to diamond problems. By pulling
the code out into a standalone mixin class that the C, C++, ObjC, and
Objc++ compilers can inherit and override as necessary we remove one
source of diamonding. I've chosen to split this out into it's own file
as the CLikeCompiler class is over 1000 lines by itself. This also
breaks the VisualStudio derived classes inheriting from each other, to
avoid the same C -> CPP inheritance problems. This is all one giant
patch because there just isn't a clean way to separate this.
I've done the same for Fortran since it effectively inherits the
CCompiler (I say effectively because was it actually did was gross
beyond explanation), it's probably not correct, but it seems to work for
now. There really is a lot of layering violation going on in the
Compilers, and a really good scrubbing would do this code a lot of good.
For consistency, it can be useful to have an explicit empty test suite list
for a test:
test('test-name', binary, suite: [])
This currently passes meson but fails when running meson tests:
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/mesonbuild/mesonmain.py", line 122, in run
return options.run_func(options)
File "/usr/lib/python3.7/site-packages/mesonbuild/mtest.py", line 1005, in run
return th.doit()
File "/usr/lib/python3.7/site-packages/mesonbuild/mtest.py", line 756, in doit
self.run_tests(tests)
File "/usr/lib/python3.7/site-packages/mesonbuild/mtest.py", line 896, in run_tests
visible_name = self.get_pretty_suite(test)
File "/usr/lib/python3.7/site-packages/mesonbuild/mtest.py", line 875, in get_pretty_suite
rv = TestHarness.split_suite_string(test.suite[0])[0]
IndexError: list index out of range
Fix it by simply checking for the test suite to be a valid list we can pass on
Fixes#5340
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Before this we only covered >, <, and ==, but we an apply some basic
logic to know that a > b == !(a <= b), or that if a > b then a != b.
This uncovered some bugs I wrote while working on this code.
We really should be testing using the operators themselves, not the
internal implementations, ie we should use a > b not a.__cmp__(b) == 1
in our tests, because __cmp__ is just an implementation detail.
This isn't safe given the way python implements default arguments.
Basically python store a reference to the instance it was passed, and
then if that argument is not provided it uses the default. That means
that two calls to the same function get the same instance, if one of
them mutates that instance every subsequent call that gets the default
will receive the mutated instance. The idiom to this in python is to use
None and replace the None,
def in(value: str, container: Optional[List[str]]) -> boolean:
return src in (container or [])
if there is no chance of mutation it's less code to use or and take
advantage of None being falsy. If you may want to mutate the value
passed in you need a ternary (this example is stupid):
def add(value: str, container: Optional[List[str]]) -> None:
container = container if container is not None else []
container.append(value)
I've used or everywhere I'm sure that the value will not be mutated by
the function and erred toward caution by using ternaries for the rest.
* coredata: store cross/native files in the same form they will be used
Currently they're forced to absolute paths when they're stored in the
coredata datastructure, then when they're loaded we de-absolute path
them to check if they're in the system wide directories. This doesn't
work at all, since the ninja backend will generat a dependency on a
file that is in the source directory unless the path was already given
as absolute. This results in builds being retriggereed forever due to
a non-existant file.
The right way to do this is to figure out whether the file is in the
build directory, is absolute, or is in one of the system paths at
creation time, and store that path as absolute. Then the code that
reads the file and the code that generates the dependencies in the
ninja backend just takes the computed list and there is no mismatch
between them.
Fixes#5257
* run_unittests: Add a test for correct native file storage
This tests the bug in #5257
Warn when someone tries to use append() or prepend() on an env var
which already has an operation set on it. People seem to think that
multiple append/prepend operations stack, but they don't.
Closes https://github.com/mesonbuild/meson/issues/5087
This creates a new command line option to store pkg_config_path into,
and store the environment variable into that option. Currently this
works like the environment variable, for both cross and native targets.
Since sanity check now includes CFLAGS, the test fails earlier.
But if the compiler is ICC, it will only fail during the build proper as
before, since that's where where the flag making `-std=unknown` an error
not warning is used.
This patch creates an enum for selecting libtype as static, shared,
prefer-static, or prefer-shared. This also renames 'static-shared'
with 'prefer_static' and 'shared-static' with 'prefer_shared'. This is
just a refactor with no behavioral changes or user facing changes.
OpenBSD doesn't have any support for the compiler sanitizers yet.
While this may change in the future, better fix test suite run in "failfast"
mode for now. This can be revisited once (if) we get support in the future.
* clang 7.0.1
$ make CFLAGS=-fsanitize=address foo
cc -fsanitize=address -o foo foo.c
cc: error: unsupported option '-fsanitize=address' for target 'amd64-unknown-openbsd6.5'
* gcc 4.2.1
*** Error 1 in /tmp (<sys.mk>:85 'foo')
$ make CC=gcc CFLAGS=-fsanitize=address foo
gcc -fsanitize=address -o foo foo.c
cc1: error: unrecognized command line option "-fsanitize=address"
* gcc 8.2.0
$ make CC=egcc CFLAGS=-fsanitize=address foo
egcc -fsanitize=address -o foo foo.c
ld: error: unable to find library -lasan
collect2: error: ld returned 1 exit status
This provides an initial support for parsing TAP output. It detects failures
and skipped tests without relying on exit code, as well as early termination
of the test due to an error or a crash.
For now, subtests are not recorded in the TestRun object. However, because the
TAP output goes on stdout, it is printed by --print-errorlogs when a test does
not behave as expected. Handling subtests as TestRuns, and serializing them
to JSON, can be added later.
The parser was written specifically for Meson, and comes with its own
test suite.
Fixes#2923.
This makes the testsuite work better with other test runners, like
pytest. This is important because better test runners are very useful to
development (e.g. avoiding running succeeding tests again and again),
even if we want to still support 0 dependency testing of Meson though
keeping the default test runnner working.
This allows the person running configure (either a developer, user, or
distro maintainer) to keep a configuration of where various kinds of
files should end up.
Instead use coredata.compiler_options.<machine>. This brings the cross
and native code paths closer together, since both now use that.
Command line options are interpreted just as before, for backwards
compatibility. This does introduce some funny conditionals. In the
future, I'd like to change the interpretation of command line options so
- The logic is cross-agnostic, i.e. there are no conditions affected by
`is_cross_build()`.
- Compiler args for both the build and host machines can always be
controlled by the command line.
- Compiler args for both machines can always be controlled separately.
macOS provides the tool `lipo` to check the archs supported by an
object (executable, static library, dylib, etc). This is especially
useful for fat archives, but it also helps with thin archives.
Without this, the linker will fail to link to the library we mistakenly
'found' like so:
ld: warning: ignoring file /path/to/libfoo.a, missing required architecture armv7 in file /path/to/libfoo.a
Instead of only doing a naive filesystem search, also run the linker
so that it can tell us whether the -F path specified actually contains
the framework we're looking for.
Unfortunately, `extraframework` searching is still not 100% correct in
the case when since we want to search in either /Library/Frameworks or
in /System/Library/Frameworks but not in both. The -Z flag disables
searching in those prefixes and would in theory allow this, but then
you cannot force the linker to look in those by manually adding -F
args, so that doesn't work.
Also add a test for it. In the process, also remove an overly-zealous
try..except statement that was catching *all* exceptions, not just
expected ones, which was masking programming errors.
Also ensure that the test's no-pkg-config codepath will always be run,
even on the CI where we always have pkg-config available.
This counts as a test case for #4728
The native file tests were never run on the CI since they were skipped
on Windows and also skipped on Linux and macOS since CC/CXX/etc are
always set by the CI.
Also fix test failure on macOS. The test was assuming that because
/usr/bin/gcc and /usr/bin/clang exist on macOS, they must be different
compilers. They're not. gcc is just a wrapper around clang, and we
correctly detect it as such.
In some cases (see #4817) it's helpful if the output file uses the
same newlines as the input file without translating them to the
platform defaults.
open() by default recognizes all newline styles and translates them
to "\n" and then to the platform default when writing.
Passing "" to "newline" disables the translation and lets us pass through
the original newline characters.
Our builddir ABI is stable across minor (stable) releases, so there is
no need to force a wipe. We already release pretty often, no need to
force people to wipe twice as often.
Jussi Pakkanen