Since this is only consulted while constructing the Dependency object, it's
result doesn't depend on the instance (and it would make no sense if it did)
Using NotImplementedError throws an ugly traceback to the user which
does not print the line number and other information making it
impossible to figure out what's causing it.
Also override it for internal dependencies because self.name is "null"
for them.
/usr/bin/env does not exist on Haiku since there's no /usr. The actual
location is /bin/env. Detect that case and directly use the
interpreter being passed to `env` in the shebang.
Also reorganize the Windows special cases which does the same thing.
The MinGW toolchain can read MinGW paths, but Python cannot and we
sometimes need to parse the libs and cflags manually (for static-only
library searching, for instance). The MinGW toolchain can always read
Windows paths with `/` as path separater, so just use that.
Also try harder to find a compiler that dependencies can use.
This means that in C++-only projects we will use the C++ compiler for
compiler checks, which can be important.
MSVC cannot handle MinGW-esque /c/foo paths, convert them to C:/foo.
We cannot resolve other paths starting with / like /home/foo so leave
them as-is so the user gets an error/warning from the compiler/linker.
These paths are commonly found in pkg-config files generated using
Autotools inside MinGW/MSYS and MinGW/MSYS2 environments.
Currently this is only done for PkgConfigDependency.
While finding an external program, we should only split the shebang
once since that is what Linux and BSD also do. This is also why
everyone uses #!/usr/bin/env in their shebangs since that allows
you to run an interpreter in a path with spaces in it.
See `man execve` for more details, specifically the sections for
interpreter scripts.
Some dependencies can be detected multiple ways, such as a config tool
and pkg-config. For pkg-config a new PkgConfigDependency is created and
used to check for the dependency, config tool dependencies are handled
ad-hoc. This allows the ConfigToolDependency to be used in the same way
that PkgConfigDependency is.
This class is meant abstract away some of the tedium of writing a config
tool wrapper dependency, and allow these instances to share some basic
code that they all need.
This basically boils down to using map() and expecting a list, but map
returns an iterator. The better solution is to use a list comprehension
anyway, so do that.
pkg-config enables to define variables by using the define-variable
option. This allows some packages to redefine relative paths, so
files can be installed in the same relative paths but under prefix.
Sometimes pkg-config can decide that the libdir is a system library dir
and must not be included in the output because that would mess up the
library search order for pkg-config libraries that must be sourced from
a non-system prefix.
However, when we're doing manual searching, we always want to see the
library directory even if it's the system path, otherwise we can't do
manual searching at all.
Escaping spaces with '\ ' is the only way that works with both
pkg-config and pkgconf, so quote that way and unquote inside Meson.
This should work on all platforms.
Also fix the unit test to do the same.
https://github.com/pkgconf/pkgconf/issues/153
When `static: true` is passed to dependency(), we parse the pkg-config
output and manually search for `-lfoo`, etc in the library paths
gathered from `-Lbar` arguments in the output.
If there are no `-L` arguments in the output, the behaviour is the
same as before. If there are `-L` arguments and we can't find a static
library, we will error out.
PkgConfig automatically removes -L paths from libdirs if the -L points
to a system path. It knows what these paths are by taking this as a
configure option at build time, which the distro maintainers set
appropriately and everything works. This allows one to have two
versions of a package installed, a system and non system, and then
override PKG_CONFIG_PATH to use the non system version, and everything
just works. For non-pkgconfig dependencies (such as LLVM) meson needs to
strip these themselves to avoid breaking the above use case.
* add support for cups dependencies
libcups has its own cups-config tool rather than using pkg-config.
This adds support for cups-config, based on pcap-config and
sdl2-config implementations.
This change also includes the unit test case and documentation for
cups dependency object implementation, and libcups2 dep to CI image.
Libpcap has its own pcap-config tool rather than using pkg-config. Add
support for pcap-config, based on the existing implementation of
sdl2-config that is there already.
It is not feasible to test all failure modes by creating projects in
`test cases/failing` that would be an explosion of files, and that
mechanism is too coarse anyway. We have no way to ensure that the
expected error is being raised.
See FailureTests.test_dependency for an example.
This class now consolidates a lot of the logic that each external
dependency was duplicating in its class definition.
All external dependencies now set:
* self.version
* self.compile_args and self.link_args
* self.is_found (if found)
* self.sources
* etc
And the abstract ExternalDependency class defines the methods that
will fetch those properties. Some classes still override that for
various reasons, but those should also be migrated to properties as
far as possible.
Next step is to consolidate and standardize the way in which we call
'configuration binaries' such as sdl2-config, llvm-config, pkg-config,
etc. Currently each class has to duplicate code involved with that
even though the format is very similar.
Currently only pkg-config supports multiple version requirements, and
some classes don't even properly check the version requirement. That
will also become easier now.
Use the compiler object to find gtest libraries. Fixes following
cases:
- cross compiling looked in host library paths
- static libgtest was not supported
Change-Id: If42cdf873db38676b99adca60752f652aff097a2
The old caching was a mess of spaghetti code layered over pasta code.
The new code is well-commented, is clear about what it's trying to do,
and uses a blacklist of keyword arguments instead of a whitelist while
generating identifiers for dep caching which makes it much more robust
for future changes.
The only side-effect of forgetting about a new keyword argument would
be that the dependency would not be cached unless the values of that
keyword arguments were the same in the cached and new dependency.
There are also more tests which identify scenarios that were broken
earlier.