Only import the ones we need for the language we are detecting, once we
actually detect that language.
This will allow finally dropping the main imports of these files in a
followup commit.
It turns out we don't generally need to proxy every compiler ever
through the top-level package. The number of times we directly poke at
one is negligible and direct imports are pretty clean.
A bunch of SystemDependency subclasses overrode log_tried() even though
they used the same function anyway. Delete them -- they still print
the same thing either way.
We use `__future__.annotations` to good effect everywhere we can, and
one of the effects of this is that annotations are automatically
stringized and don't need to be evaluated, using less memory and
computation. But this only affects actual annotations -- a cast is just
a function with an argument, so the compiler has no idea that it's an
annotation to be stringized.
Do this manually.
These are only used for type checking, so don't bother importing them at
runtime.
Generally add future annotations at the same time, to make sure that
existing uses of these imports don't need to be quoted.
JNI is a more apt name because it currently only supports the JNI. I
also believe that CMake uses the terminology JNI here as well.
JNI is currently the only way to interact with the JVM through native
code, but there is a project called "Project Panama" which aims to be
another way for native code to interact with the JVM.
All these dependencies are impossible to find on versions of Meson older
than the ones they got custom lookups in, because they don't provide
pkg-config files. So they should not / cannot be reasonably used on
older versions, and it is easy to say "yep, these should emit a
FeatureNew for the versions they got added in".
Contrary to most system method checks, zlib currently functions as a
whitelist of OSes. This isn't really needed however. The first special
case for OSes that provide zlib as part of the base OS is worth keeping.
However, the elif for windows is more than generic enough to allow any
other potential OSes to try. Just make it a simplie if/else instead.
Both of these are artifacts of the time before Dependency Factories,
when a dependency that could be discovered multiple ways did ugly stuff
like finding a specific dependency, then replacing it's own attributes
with that dependency's attributes. We don't have cases of that left in
the tree, so let's get rid of this code too
* 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>
* depenencies/llvm: Handle llvm-config --shared-mode failing
Fixes: #7371Fixes: #7878
* test cases/llvm: Refactor to use test.json
Instead of trying to cover everything internally
has_header returns a tuple of (found: bool, cached: bool), so `if
has_header` will always return true because the tuple is non-empty. We
need to check if the found value is true or not.
I've tested this on FreeBSD, and dragonfly's userland is close enough
I'm willing to call it good without testing. OpenBSD and NetBSD also
have a zlib in their base configurations, but I'm not confident enough
to enable those without testing.
This comes pre-installed, but currently we don't have a way to detect it
without relying on pkg-config or cmake. This is only valid with the
apple clang-based compilers, as they do some special magic to get
headers.
Currently PkgConfig takes language as a keyword parameter in position 3,
while the others take it as positional in position 2. Because most
dependencies don't actually set a language (they use C style linking),
using a positional argument makes more sense. ExtraFrameworkDependencies
is even more different, and duplicates some arguments from the base
ExternalDependency class.
For later changes I'm planning to make having all of the dependencies
use the same signature is really, really helpful.
This moves most of the execution code from the CMakeInterpreter
into CMakeExecutor. Also, CMakeTraceParser is now responsible
for determining the trace cmd arguments.
Some slight refactoring for the dependency classes and
I switched the elbrus compiler to the GnuLikeCompiler.
This is also the correct use according to the documentation
of GnuLikeCompiler.
Both scan-build and llvm-config need the same list of LLVM version
suffixes. It is better to keep the list at a common place instead of
having several copies in different files, which is likely to become
out-of-sync when the list is updated.
Cmake ignores shared vs dynamic linking, and always returns static. This
went unnoticed, but results in regresssions for mesa. We need to fix
cmake, but with 0.51.1 due out shortly switching the order provides a
quick fix to restore expected functionality seems acceptable.
Fixes#5568
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.
Tristan Partin