Specifically, wherever we have sources or outputs, we want to use an
OrderedDict so that the build is always deterministic. It was reported
by Olexa Bilaniuk that `ar D` creates static libraries with different
checksums depending on the order of the object files.
See: https://github.com/mesonbuild/meson/pull/951
We don't actually want to preserve the order in which they are listed.
We just want the order to be deterministic and predictable.
Not only does extract_all_objects() now work properly again,
extract_objects() also works if you specify a subset of sources all of
which have been compiled into a single unified object.
So, for instance, this allows you to extract all the objects
corresponding to the C sources compiled into a target consisting of
C and C++ sources.
The use of has_dir_part is a terrible back that we need to move away
from. This will eventually be fixed by always using File() objects
everywhere. For now, this is needed for unity builds to work.
This is the first step in making Vala support have feature-parity with
C/C++ support. Vala and Vapi sources generated with Generators and
CustomTargets are no longer ignored. Dependencies are setup properly and
they are added to the commandline.
Pre-calculate the output directory for GeneratedList and CustomTarget so
we can directly use the same code for both while compiling C/C++ files
and headers.
There is no reason to have separate branches for GeneratedList and
CustomTarget since both can be used in almost exactly the same way for
generating sources.
This is going to used next for adding generated sources support to Vala.
This isn't useful yet because we currently only have dependencies for
C/C++ targets (the rest all use link deps), but we will need this for
Vala, Rust, and more.
get_filename() made no sense for CustomTarget since it can have multiple
outputs. Also use get_outputs() for GeneratedList since it has the same
meaning and remove unused set_generated().
As a side-effect, we now install all the outputs of a CustomTarget.
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.
Jussi Pakkanen
Guillaume Poirier-Morency
Nirbheek Chauhan
Elliott Sales de Andrade
Nirbheek Chauhan