This is done by adding a new compiler method called 'no_warn_args' which
returns the argument(s) required for the compiler to emit no warnings
for that compilation.
This take care of not disabling warnings for C code compiled into the
BuildTarget. Also includes tests for ensuring all this.
https://github.com/mesonbuild/meson/issues/864
Otherwise they are built regardless of whether they are actually used by
anything else. Only build them if they're going to be installed or
always-built.
Ideally, we should also do this with all BuildTargets, and provide
a mechanism for people to specify which targets they want built with
'all', and a way for people to add them to custom targets.. Without
this, things like tests and examples are *always* built with no way to
turn that off.
For now, we just do this because it also with tests that check for
dependency issues. Including all CustomTargets in `all` results in
dangling targets to also be built, which hides the problem and makes it
racy.
self.dep_rules is not set anywhere by anything, so this code always
results in a no-op. If it didn't result in a no-op, it would need to be
seriously rewritten because it has bitrotten and makes no sense anymore.
This is definitely more correct since it takes into account the
cross-compilation status. We also now do the Java and CSharp sanity
checks on the BuildTarget level instead of in the Ninja backend.
Because we were iterating over all generated sources of a target in one
go, we weren't adding the correct header_deps for generated source
compiles. We need to aggregate the header_deps first before generating
source compile targets for generated source files.
For commands that always output to stdout and don't have a "-o" or
"--output" or some other similar option, this 'capture' setting allows
the build to capture the result and place it in the output file.
Trivially correct typo fix. Didn't actually break anything because the
fallback is libdir anyway, and we always install static libraries to
libdir.
Pointed out by Zhe Wang (0x1997).
This commit contains several changes to the naming and versioning of
shared and static libraries. The details are documented at:
https://github.com/mesonbuild/meson/pull/417
Here's a brief summary:
* The results of binary and compiler detection via environment functions
are now cached so that they can be called repeatedly without
performance penalty. This is necessary because every
build.SharedLibrary object has to know whether the compiler is MSVC or
not (output filenames depend on that), and so the compiler detection
has to be called for each object instantiation.
* Linux shared libraries don't always have a library version. Sometimes
only soversions are specified (and vice-versa), so support both.
* Don't use versioned filenames when generating DLLs, DLLs are never
versioned using the suffix in the way that .so libraries are. Hence,
they don't use "aliases". Only Linux shared libraries use those.
* OS X dylibs do not use filename aliases at all. They only use the
soversion in the dylib name (libfoo.X.dylib), and that's it. If
there's no soversion specified, the dylib is called libfoo.dylib.
Further versioning in dylibs is supposed to be done with the
-current_version argument to clang, but this is TBD.
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html#//apple_ref/doc/uid/TP40002013-SW23
* Install DLLs into bindir and import libraries into libdir
* Static libraries are now always called libfoo.a, even with MSVC
* .lib import libraries are always generated when building with MSVC
* .dll.a import libraries are always generated when building with
MinGW/GCC or MinGW/clang
* TODO: Use dlltool if available to generate .dll.a when .lib is
generated and vice-versa.
* Library and executable suffix/prefixes are now always correctly
overriden by the values of the 'name_prefix' and 'name_suffix' keyword
arguments.
Previously Meson would use the name of the first .vala source file. This
doesn't work for some projects. Tracker is one example: it has
several libraries that mix Vala and C code. In such cases, none of the
.vala files tend to bear the name of the library we actually want to
generate.
This allows defining test suites for test-valgrind target without the risk
of e.g. being unable to differentiate the targets test-valgrind (testing
with valgrind) from test-valgrind (testing the valgrind subproject).
Nirbheek Chauhan
Jussi Pakkanen
Elliott Sales de Andrade
Nirbheek Chauhan
Sam Thursfield
Martin Hostettler
Hemmo Nieminen
Nicolas Schneider