Create GL dependency objects via a factory function, so they can be the
correct type of object (e.g. a PkgConfigDependency when it's found by
pkg-config)
Factor out method: kwarg processing, so it can be used by the factory before
the dependency object is constructed
This code isn't used as present: the actual objects we use and which get
pickled are either static subclasses of ConfigToolDependency, or special
purpos subclasses of Dependency which get attributes copied from an instance
of a dynamic subclass of ConfigToolDependency which is then discarded.
This is fortunate, as it doesn't work: the pickled reduction is a call to
the dynamic subclass's constructor, but the superclass constructors rely on
the environment object being fully initialized, which hasn't happened yet
during unpickling.
Avoid this by having a pickled reduction which is just a call to create the
dynamic subclass object, and relying on the default __setstate__ behavior to
unpickle the object's __dict__.
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)
Because FreeBSD's llvm-config adds -l/usr/lib/libexecinfo.so when asked
for system-libs, which is bogus. We'll remove the leading -l from any
argument that also ends with .so.
Special case ThreadDependency by taking compiler's flags and
PkgConfigDependency by adding them in requires(.private) instead. For
other Dependency objects just take their link_args and compile_args.
Closes#2725
If LLVM is built from a git mirror instead of from SVN it will have
"git-<very short sha>" at the end of the version. We need to remove that
so that version comparison will work correctly.
Fixes: #2786
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.
The sysconfig config variables are different on MSYS2 and the paths
are also different. We now also use the full path to the import or
static library instead of using -Lfoo -lpython35 etc.
Also obey the value of the 'static' keyword argument.
sysconfig.get_platform() returns 'mingw' with MSYS2, so we need to
use some other method; in this case I chose to use the CC that
Python was compiled with, which is a relatively reliably indicator
unless people start using Python on Windows compiled with Clang or
something.
/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.
Jon Turney
Christophe Gouiran
Nikita Churaev
Dylan Baker
Benjamin Redelings
Niklas Claesson
Xavier Claessens
Alexis Jeandet
Nirbheek Chauhan
Niklas Claesson
Iñigo Martínez
Josh Soref