Also C++ compilers can build .S assembly files. This wasn't noticed
earlier because most people were also using C compilers in their C++
projects and we would fall back to using the C compiler for building the
assembly files. Now we have a test for this.
This was trivial to add; except that we needed a new LLVM IR rule
because the compiler emits warnings if you pass any special arguments to
it such as include arguments or dependency arguments.
Closes#1089
Instead of adding it everywhere manually, create a wrapper called
mesonlib.Popen_safe and use that everywhere that we call an executable
and extract its output.
This will also allow us to tweak it to do more/different things if
needed for some locales and/or systems.
Closes#1079
Sometimes we want to restrict the acceptable versions to a list of
versions, or a smallest-version + largest-version, or both. For
instance, GStreamer's opencv plugin is only compatible with
3.1.0 >= opencv >= 2.3.0
Move CCompiler.compile to Compiler.compile so that ValaCompiler can use
it. Also rewrite ValaCompiler.sanity_check to use it since it does
a simple compile check.
At the same time, it enhances ExternalLibrary to support arguments for
languages other than C-like.
Includes a test for this that links against zlib through Vala.
Closes#983
Since Vala require 'glib-2.0' and 'gobject-2.0' dependencies, it's
better to fail at 'valac' step with meaningful error.
Add missing 'gobject-2.0' dependency on the mixed source test case.
With MSVC 2013 and newer, using pre-compiled headers with .pdb debugging
fails with the following error message:
fatal error C1041: cannot open program database '[...]\prog.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS
So we use /FS when PCH is enabled. When PCH is enabled and debugging is
disabled, this will have no effect since .pdb files will not be written.
We already pass everything else (custom targets, build targets, etc) as
absolute paths, and this is the only sane way to handle this till we
rework the codebase to use File objects everywhere (after reworking the
File object itself).
Fixes https://github.com/mesonbuild/meson/issues/957
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.
Nirbheek Chauhan
Jussi Pakkanen
Thibault Saunier
Guillaume Poirier-Morency
Thibault Saunier
Patrick Griffis
Tim-Philipp Müller