* dependencies: Deterministic LLVM compile and link arg ordering
In LLVMDependencyConfigTool, the members compile_args and required_modules are
either converted to or stored as sets, which do not have a stable ordering. This
results in nondeterministic builds, particularly with required_modules causing
the order in which the LLVM libraries are linked in to the output binaries to
change across independent builds. As any guarantee about ordering for
compile_args is lost by being converted from a list to a set and back, and the
modules added to required_modules was even already sorted once, sort both when
converting them to lists.
* Use mesonlib.OrderedSet instead of sorting the sets.
Co-authored-by: Kaelyn Takata <kaelyn.alexi@protonmail.com>
Currently all arguments are being passed to scan-build as part of the
refactoring of how Meson internally handles arguments, but that's wrong,
only project specific arguments are supposed to be passed.
Fixes: #8818
This is useful both from the perspective of optional functionality that
requires a module, and also as I continue to progress with Meson++,
which will probably not implement all of the modules that Meson itself
does.
`qt.preprocess` dispatches to the individual methods instead of
duplicating all of the logic itself, but this means that it goes through
the type checking, and feature checking a second time. To avoid this we
need to use a private helper method instead.
Fixes#8920
This commit introduces a new type of `HoldableObject`: The
`SecondLevelHolder`. The primary purpose of this class is
to handle cases where two (or more) `HoldableObject`s are
stored at the same time (with one default object). The
best (and currently only) example here is the `BothLibraries`
class.
Logs are printed only when the task is done to not interleave logs while
running multiple tasks in parallel. That means that nothing is printed
until the task is done and that could take time.
This moves all the code into a class and call its run() method in a
thread. The class queues all logs to print them at the end to avoid
mixing output of multiple actions.
* backends: Add a Visual Studio 2013 backend
This is more-or-less a quick port from the VS2015 backend, except that
we update the Visual Studio version strings and toolset versions
accordingly. Also correct the generator string for Visual Studio 2015
in mesonbuild/cmake/common.py.
* backend: Add VS2012 backend
Similar to what we did for Visual Studio 2013, add a Visual Studio 2012
backend.
* vs2010backend.py: Implement `link_whole:` if needed
We actually need Visual Studio 2015 Update 2 to use `/WHOLEARCHIVE:`,
which is what we are currently using for `link_whole:` on Visual Studio.
For Visual Studio versions before that, we need to expand from the
static targets that were indicated by `link_whole:`, and any of the
sub-dependent targets that were pulled in via the dependent target's
`link_whole:`. This wil ensure `link_whole:` would actually work in
such cases.
* vs2010backend.py: Handle objects from generated sources
Unforunately, we can't use backends.determine_ext_objs() reliably, as
the Visual Studio backends handle this differently.
* vs2010backend.py: Fix generating VS2010 projects
Visual Studio 2010 (at least the Express Edition) does not set the envvar
%VisualStudioVersion% in its command prompt, so fix generating VS2010
projects by taking account into this, so that we can determine the location
of vcvarsall.bat correctly.
* whole archive test: Disable on vs2012/2013 backends too
The Visual Studio 2012/2013 IDE has problems handling the items that would be
generated from this test case, so skip this test when using
--backend=vs[2012|2013]. This test does work for the Ninja backend when
VS2012 or VS2013 is used, though.
Consolidate this error message with XCode along with the vs2010 backend.
* docs: Add the new vs2012 and vs2013 backends
Let people know that we have backends for vs2012 and 2013. Also let
people know that generating Visual Studio 2010 projects have been fixed
and the pre-vs2015 backends now handle the `link_whole:` project option.
The existing code works, but it probably doesn't do what the author
thought it would do. `(x or y or z) is not None` works by checking that
each of those things are *truthy* in turn, and returning the first
truthy value, which is compared against None. Using `all()` makes it
very clear that what you want to do is make sure that each value is not
None.
There's no reason to allow None into the backend, it already has code to
check that all of the values of the FileMode object are None, so let's
use that, which is much simpler all the way down.