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.
* Fixed spelling
* Merged the Buildoptions and Projectinfo interpreter
* Moved detect_compilers to Environment
* Added removed test case
* Split detect_compilers and moved even more code into Environment
* Moved set_default_options to coredata
* Small code simplification in mintro.run
* Move cmd_line_options back to `environment`
We don't actually wish to persist something this unstructured, so we
shouldn't make it a field on `coredata`. It would also be data
denormalization since the information we already store in coredata
depends on the CLI args.
The returned not-found object can be from any type because we were
returning the first of the failed attempts. It also can happen that we
don't have any dependency object in which case we should just return
NotFoundDependency() object as well instead of raising an exception.
That exception was happening before, but dependency_impl() was
calling find_external_dependency() in a try block so it was hidden.
This seems to be related to deleting the current working directory.
Simply deleting all of the trees inside the build directory instead
seems to fix it. This only appears with some combination of generated
targets, running the test case against say "1 trivial" doesn't show the
bug.
See this mesa bug: https://bugs.freedesktop.org/show_bug.cgi?id=109071
Since `_process_libs` appends the lib's dependencies this list already,
the final return value of `_process_libs` will end up after its
dependencies, which is the wrong way around. (The lib must come first,
then its dependencies)
The easiest solution is to simply pre-pend the return value of
`_process_libs` rather than appending it, so that its dependencies come
after the library itself.
Closes#4091.
llvm-config --libfiles --link-shared wants to link to a bunch of shared
libraries which don't exist, so we end up at dev.py:308, but the guess
that makes ('libLLVM*.dll') doesn't take into account the existence of
implibs (which is fixable), but even if it did 'libLLVM-7.0.dll.a'
doesn't seem to exist... so not sure how to fix this...)
Also some steps towards making that work:
Adjust helper_create_binary_wrapper for MSYS2. The .bat wrapper should
run msys2 python, not try to invoke the 'py' python launcher (which may
not be present)
Suppress echoing of the command in helper_create_binary_wrapper
(otherwise the echoed command can interfere in interpreting the output
of the wrapped command, which seems to be the case when it's
llvm-config)
This variant was added to allow introspection before configuring a build
directory. This is useful for IDE integration to allow displaying and/or
setting options for the initial configuration of the build directory.
It also allows showing basic information about the project even if it's
not yet configured or configuring failed.
The project 'name' field in --projectinfo is used inconsistently:
For the top level project it always shows the name configured in
the top level meson.build file. For subprojects it's referring to the
name of the directory the subproject's meson.build is contained in.
To have a consistent output and preserve the existing behavior this adds
the 'descriptive_name' field which always shows the name set in the
project.
To be consistent the 'descriptive_name' field was also added to the
--projectfiles variant that uses an already configured build.
It also extends the information shown with the list of buildsystem-files.
This is currently only implemented in the variant for unconfigured
projects.
Fixed-size hash makes paths shorter and prevents doubling of path length
because of subdir usage in target id: "subdir/id" would generate
"subdir/{subdir-without-slashes}@@id" target otherwise.
Export construct_id_from_path() to aid tests.
Add a separate unit test for this function to make sure it is not broken unexpectedly.
Closes#4226.
this adds support for generating pkgconfig files for c#.
The difference to c and cpp is that the -I flag is not known to the c#
compiler, but rather the -r flag which is used to link a .dll file into
the compiled library.
However this opens the question of validating which pkgconfig files can
be generated (depending on the language).
This implements 4409.
part of using ICC is configuring LD_LIBRARY_PATH so that you can link
with several Intel specific .so's. Currently meson blanket overrides the
LD_LIBRARARY_PATH in several tests which breaks them. Instead prepend
the test dir td LD_LIBRARY_PATH. Fixes 6 tests with ICC.
This commit adds a nice decorator helper for skipping tests when they
require the compiler to implement a specific base option, and uses it to
turn off b_sanitize tests, which fixes some tests on ICC.
samu prints a different message when the build is a no-op, so make
assertBuildIsNoop consider that as well.
Also, if compile_commands.json cannot be found, just skip the test. This
seems reasonable since meson just produces a warning if `ninja -t compdb`
fails.
Finally, only capture stdout in run_meson_command_tests.py, since the
backend may print messages the tests don't recognize to stderr.
Fixes#3405.
Raphael Salamon