DMD and LDC are a real pain to use as linkers. On Unices they invoke the C
compiler as the linker, just like meson does. This means we have to figure out
what C compiler they're using and try to pass valid arguments to that compiler
if the D compiler doesn't understand the linker arguments we want to pass. In
this case that means gcc or clang. We can use-the -Xcc to pass arguments
directly to the C compiler without dmd/ldc getting involved, so we'll use that.
This was never really true of the D compilers, it made them more
complicated than necessary and was incorrect in many cases. Removing it
causes no regressions on Linux, at least in our rather limited test
cases).
Compiler is invariant, in other words Compiler and only Compiler can
fulfull it, it's derived classes cannot be used. CompilerType is
covariant, that is Compiler and any derived class can fulfill it. This
fixes a number of issues in the boost module.
This makes the typing annotations basically impossible to get right, but
if we only have one key then it's easy. Fortunately python provides
comprehensions, so we don't even need the ability to pass multiple keys,
we can just [extract_as_list(kwargs, c) for c in ('a', 'b', 'c')] and
get the same result.
These are basically doing what mlog.log(..., once=True) does, so lets
just use that. The once argument to mlog is newer, so these probably
should have been changed already.
listify shouldn't be unholdering, it's a function to turn scalar values
into lists, or flatten lists. Having a separate function is clearer,
easier to understand, and can be run recursively if necessary.
The old logic was completely broken, and didn't even assert that the
specified section was found at all. The CPU families test was broken
because of this. Luckily, the table didn't go out of sync with the
code.
It now also doesn't assume that each section has only one table. This
fixes the test now that we document the buildtype/optimization/debug
mapping in a second table inside the `Universal options` section.
Otherwise you have to hunt through the source code. Specifically, this
is defined in `mesonbuild/coredata.py`: `set_buildtype_from_others()`
and `set_others_from_buildtype()`
As any child of BuildTargetHolder might need the name of the object,
provides a method to get object name.
This is useful in gst-build to display the plugin name and not
the filename.
This commit annotates most of interpreterbase.py. However,
there are stil the @wraps missing, since I am unsure what
the types are supposed to be here.
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.
the check for which files can be compiled are called again and again on
the same files over and over again. Caching this here shaves off 11s of
the build time of efl (which has grown in the last 3 versions to over 40
sec. again)
in order to deduplicate arguments as much as possible, we need to check
if a argument is already part of the list. Which is quite slow because
we are checking 3 lists for that.
In smaller projects this might be not of interested. However, in efl
things are quite "heavy", alone generating the ninja file took 40 sec..
16 sec. are spent in __iadd__ of CompilerArgs.
What this patch does to speed this all up is:
1. We only check if a element is in post when we know that it must be in
post same for pre.
2. the checks for if we already do contain a specific value are now done
via a dict, and not via the list.
This overall brings the time from 16 sec. spent in __iadd__ to 9 sec. in
__iadd__.
Another possible solution for all this is to have a internal structure
of CompileArgs of trees, so you have the "basic" layer of arguments
where the position does not matter. Additionally, you have two stacks of
lists, the pre stack and the post stack, duplicates can then be checked
when itereting, which would safe another ~4s in terms of efl. However, i
do not have time for this undertaking right now.
Currently, detect_machine_info() is called:
- from Environment.__init__(), before we have any compiler available
- from Interpreter.__init__() with the list of languages provided to
project() (determined via the initial parse_project())
This is not sufficent in the case where no languages are specified to
project() and are later added with add_languages().
We cannot correctly detect that the host machine should be treated as
x86 (on x86_64 hardware) until we have a compiler we are told to use.
Redetect machines after project(), and after every add_languages().
Running the build step of test '127 custom target directory install'
again, using the VS backend, causes 'docgen.py' to try to create the
target directory again (which fails with a FileNotFound exception).
I'm guessing that perhaps this is a shortcoming of the VS backend that
it doesn't correctly give this target a dependency on the directory.
I'm not sure that this test is actually valid meson: the reference
manual says custom_target(output:) should be a list of files, and not a
directory, as is this case here.
Add coverage of a simple 'configure then build' sequence, to catch bugs
which occur with that.
Also, to simplify returning results from functions called by
_run_test(), allow it also throw TestResult objects, which run_test()
catches and returns.
Test that the host_machine is correctly detected after add_languages(),
when no langauge is initially specified in project().
In the MSYS2 MSYSTEM=MINGW32 environment (64-bit MSYS2 but with a
i686-w64-mingw32 targeted gcc as gcc) this test fails, as it
(incorrectly) tries to build retval-x86_64.S using an x86 compiler.
There were two things mypy was warning about:
1) it doesn't understand hasattr()
2) It was possible for mlog.{error,warning,deprecation} to get passed
multiple values for the once keyword argument.
Dylan Baker
Amit D
Daniel Mensinger
Xavier Claessens
Nirbheek Chauhan
Stéphane Cerveau
Martin Storsjö
Michael Brockus
Michael
Stephan Lachnit
Jussi Pakkanen
Marcel Hollerbach
Jon Turney
ur4t