Instead of adding it everywhere manually, create a wrapper called
mesonlib.Popen_safe and use that everywhere that we call an executable
and extract its output.
This will also allow us to tweak it to do more/different things if
needed for some locales and/or systems.
Closes#1079
On Windows, we can build with both 32-bit and 64-bit compilers, but the
Python is either 32-bit or 64-bit. Check the architecture of the found
Python libraries and don't use them if they don't match our
build_machine.
Also skip the tests if the Python 3 dependency is not found.
Sometimes we want to restrict the acceptable versions to a list of
versions, or a smallest-version + largest-version, or both. For
instance, GStreamer's opencv plugin is only compatible with
3.1.0 >= opencv >= 2.3.0
qmake for both Qt4 and Qt5 detection was assuming that it was only used
on Windows, which is incorrect. It can also be used on Linux for
cross-compilation or in general when pkg-config is not available.
It was also not failing properly for both Qt5 and Qt4 when no libraries
were found, and was assuming that the .dll was always available.
Qt4 detection with qmake was also completely broken.
Also prevents unwanted injection of partially-found qt dependencies in
targets by unsetting self.cargs and self.largs
Move CCompiler.compile to Compiler.compile so that ValaCompiler can use
it. Also rewrite ValaCompiler.sanity_check to use it since it does
a simple compile check.
At the same time, it enhances ExternalLibrary to support arguments for
languages other than C-like.
Includes a test for this that links against zlib through Vala.
Closes#983
* Simpler picking of pkg-config vs qmake detection
* qmake-based detection now allows specifying qmake via cross-info
* bindir is now stored from qmake/pkg-config detection and can be used
to detect qt tools such as moc, uic, rcc with self.compilers_detect()
* Qt4 dependencies got some love; now they share the implementation with
Qt5 since the two are very similar; basically identical
* Don't ask about Qt3
And remove the InternalDependencyHolder class.
In some cases we need to know the type of dependency we are
dealing with. For example in GStreamer if the dependency
is not an internal one, then we need to get some env var
from pkg-config to know where to find some plugins necessary
to run some tests.
Reduces duplicated code, and also use universal_newlines=True which
avoids having to decode the bytes output to string.
We mostly need this so we can pass the *current* process environment to
pkg-config which might've changed since the module was imported. Without
this, subprocess.Popen invokes pkg-config with a stale environment (used
in the unittest added later)
Fixes https://github.com/mesonbuild/meson/issues/526
Also removes useless and incorrect mesonlib.is_32bit() function. We
cannot trust that the architecture that Python is built for is the same
as the one we're targetting.
Because of how files and executables work on Windows, scripts that use
an interpreter must have an extension, and that extension must be
associated with an interpreter. The full list of executable extensions
is available in the PATHEXT environment variable.
However, UNIX-like OSes use an executable bit and read the shebang to
figure out what interpreter to use, and the scripts don't need to have
extensions. We can now detect these scripts using find_program by
manually searching in PATH and reading the shebang.
This gives a clearer output when the dependency is not required or has a
fallback subproject otherwise the user is left wondering why the optional
dependency wasn't used or why the fallback subproject is being used.
Just exit immediately when there's no pkg-config file found instead of putting
everything else in a huge 'else:'. Much clearer and avoids one level of
indentation.
No code changes accompany this.
This allows a project to use the same fallbacks dependency from the same
subproject multiple times in the same way that external dependencies can be.
Also change the format of the dependency identifier to ensure that fallback
checks with different dirname/varname aren't mistakenly reused. We now use
a tuple for this because the format is simpler to construct and it gives us the
same immutability guarantees as a string which is needed for using it as
a dictionary key.