This is much more accurate since this is actually what determines what
file naming to use and whether there will be PDB debugging information
or not.
Closes#1169
This greatly improves the logic for determining the linker. Previously,
we would completely break if a target contained only extracted objects
and we were using more than one compiler in our project.
This also fixes determination of the linker if our target only contains
generated objc++ sources, and other funky combinations.
This avoids us having no compilers at all for targets that are composed
entirely of objects with no sources.
Now we will always have a compiler for a target even if it is composed
entirely of objects generated with custom targets unless it has
completely unknown sources.
Everywhere we use this object, we end up iterating over it and comparing
compiler.get_language() with something. Using a dict is the obvious
choice and simplifies a lot of code.
The error message is misleading (talks about external dependencies), and
doesn't tell you what you need to do (use the output of
declare_dependency, dependency, or find_library). At the same time
rename add_external_deps to add_deps since it adds internal deps too.
Plus many more error message improvements all over the place.
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.
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.
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.
With C/C++, on Windows you don't need to pass any arguments for a static
library to be PIC. On UNIX platforms you need to pass -fPIC.
Other languages such as D have compiler-specific PIC arguments required
for PIC support in static libraries on UNIX platforms.
This kwarg allows people to specify which static libraries should be
built with PIC support. This is usually used for static libraries that
will be linked into shared libraries.
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.
When the BuildTarget (executable, shared-library, static-library, etc)
is created, process the source list and assign compilers to this target.
This allows us to do compiler-specific file-naming without resorting to
ugly hacks.
This is one step towards consolidating all the 'what language does this
target use' checks and the 'this target should only have $lang files as
sources' checks we have all over the codebase. All those checks should
be done only when the target is created.
Add support for passing a description to configuration data
setter methods via a 'description' kwarg. The description
string will be used when meson generates the entire configure
file without a template, autoconf-style.
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.
Nirbheek Chauhan