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.
The new implementation will correctly pick boost from 3 possible
locations on windows and two locations on posix compatible OSs.
The new search algorithm also differentiates between debug and
release builds of Boost and multi or single threading builds.
It was also decided to map "Meson modules" to Boost software libraries
and not Boost modules since it there are a lot of options regarding
linking. Some modules can even be used either as headers-only or with
dynamic linking.
This commit also fixes a bug that prevented header-only use on Windows.
Fixes: #2274#2239#1803#669
This allows the logic in a meson.build file to be simplified (ie, some
dependencies can add the same module requirements) but meson will only
check for them once. Since set is inherently unordered, use sorted to
make the output deterministic.
* 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.
We prefer pkg-config files, though only OpenMPI supplies them.
Otherwise, check environment variables and search for wrappers and ask
them for what to do.
Fix an error in the windows vulkan_sdk library finding.
Also don't fail the vulkan test only because no vulkan
driver is installed (should fix the travis error).
Rework the vulkan module:
- adopt the VULKAN_SDK paths for its linux version
- add sanity tests for the VULKAN_SDK path
- add guessing as last fallback, needed on linux systems
on which no vulkan pkgconfig is installed [ubuntu atm]
- restructure exception handling/branching
Not tested on windows yet.
This was broken because the class property will say True but the
object property will not be set. Store the value on the class property
and transfer to object in __init__. Just like PkgConfigDependency.
Boost tests are disabled on Windows for now because the detection
is actually completely broken. Once that's fixed (after the release)
we can enable it again.
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.
This commit syncs the list with gnome-builder, which updates its list
in https://bugzilla.gnome.org/show_bug.cgi?id=782296.
llvm-config40 is added becaue LLVM 4.0 becomes a stable release.
llvm-config-5.0 is added to the bottom of the list because it is still
a development snapshot (svn trunk).
This was already mostly working before due to how the linker arguments were constructed, but this will now be more resilient to the case where dynamic libraries only are present.