Doing this by hand is fraught with corner cases, and we're running into
some of those problems already. setuptools pkg_resource is a well tested
solution for not running into corner cases, and we already rely on
setuptools to make our entry point scripts work, so we might as well
make us of the other things it can solve for us.
Fixes#6801
This also fixes that the keys in ArgumentNode.kwargs are
all of the type BaseNode now. Before this commit, it was
possible that both strings and Nodes where used as keys.
Do this by tracking CMAKE_CURRENT_{SOURCE,BINARY}_DIR variables.
This is achieved by injecting CMake code with CMAKE_PROJECT_INCLUDE
and overriding some builtin functions with a wrapper that adds
additional trace information.
This moves most of the execution code from the CMakeInterpreter
into CMakeExecutor. Also, CMakeTraceParser is now responsible
for determining the trace cmd arguments.
This fixes an issue with generated sources and object libraries, as
well as an issue on windows with the `link` linker and the vs backend.
The last issue is resolved by building the source files multiple times
to avoid extracting object files in meson.
This PR refactors the old output_target_map, which was a
raw dict, into it's own class. This makes the access to
the map more uniform and robust (at the cost of more lines
of code).
Additionally relative paths to the build directory are
now also tracked for outputs. This is neccessary to
corretcly distingluish files with the same name, that are
in different directories.
Previously, warnings genereated in CMake were not logged because
CMake sends them to stderr alongside the trace information. With
this PR, only real trace lines are send to the trace parser and
all other lines in stderr are logged as warnings.
The file API will automatically be used when CMake >= 3.14
is detected. This new API is meant as a replacement for the
now deprecated CMake server API.
The new API (mostly) provides the same information in a
different format. Thus only a slight bit of refactoring was
necessary to implement this new backend
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
Now, all source files are ignored that are not part of the
language of the target. This is also what CMake does.
Additionally it is now supported to build source files that
are generated inside the build directory.
Dylan Baker