Those tools use our arguments to build a file and execute it to
introspect it at runtime. However, they do not know that you can pass
the full path to the library to use, and ignore the arguments.
The long-term fix for this is to have them output a .c file that Meson
will build for them, which they can then run, but that will require
upstream changes:
https://gitlab.gnome.org/GNOME/gtk-doc/merge_requests/1
Closes https://github.com/mesonbuild/meson/issues/3774
A number of cases have to be taken care of while doing this, so
refactor it into a helper on ExternalProgram and use it everywhere.
1. Command is a list of len > 1, use it as-is
2. Command is a list of len == 1 (or a string), use as a string
3. If command is an absolute path, use it as-is
4. If command is not an absolute path, search for it
* Add a test case for bad de-dup of -framework args
https://github.com/mesonbuild/meson/issues/3800
* pkgconfig: Don't naively de-dup all arguments
Honestly don't know what I was smoking. Of course the `Libs:` field in
a pkg-config file can have arguments other than -l and -L
Closes https://github.com/mesonbuild/meson/issues/3800
* pkgconfig module: Fix needlessly aggressive de-dup
The name splitting was wrong and would not incorrectly handle folders
with two dots, like Foo.framework.dSYM and treat this as 'Foo' instead
of 'Foo.framework', which would lead to meson detecting dSYM bundles
as frameworks and try to use those like a framework, which is wrong.
Fix#3793
D is not a 'c-like' language, but it can link to C libraries. The same
might be true of Rust in the future and Go when we add support for it.
This contains no functionality changes.
All dependencies were using find_library, has_header, get_define, etc on
self.compiler assuming that it's a compiler that outputs and consumes
C-like libraries. This is not true for D (and in the future, for Rust)
since although they can consume C libraries, they do not use the
C ecosystem.
For such purposes, we now have self.clib_compiler. Nothing uses
self.compiler anymore as a result, and it has been removed.
Currently, ExternalProgram get_path() assumes the last component in the
path is always the actual command path. However, this is not always
right. For example, in the command "python -u", we should return
"python" and not "-u". However, in other cases, like "python script.py",
then the last component is the right one.
The heuristic that seems to capture this is to use the last argument
that is still a file. This means options get ignored, but "python
script.py" still works. Let's use this heuristic, at least for now.
This adds a new method, partial_dependency to all dependencies. These
sub dependencies are copies of the original dependency, but with one or
more of the attributes replaced with an empty list. This allows creating
a sub dependency that has only cflags or drops link_arguments, for
example.
This halves the configure time in gst-build, the aggregate of all
GStreamer repositories.
We can't do this to Popen_safe because we can't be sure that other
programs have no side-effects and will always return the same output
for the same arguments and environment.
Strawberry Perl on Windows ships with a Perl implementation of
pkg-config embedded inside a BAT file. True horror of horrors, but
people do use it, so search for pkg-config with ExternalProgram which
has the right Windows-specific cases to deal with that.
Closes https://github.com/mesonbuild/meson/issues/3221
Unusually, the cygwin package for openmpi installs headers into
/usr/include, rather than /usr/include/openmpi
Prevent pkg-config from suppressing that -I flag, so a gfortran INCLUDE can
find those files
Also don't resolve -lfoo args only when libpaths are defined.
cc.find_library() also searches in the toolchain directories, and the
static library might be there.
A hard error makes this feature useless in most cases since a static
library usually won't be found for every library, particularly system
libraries like -lm. Instead, warn so the user can provide the static
library if they wish.
This feature will be expanded and made more extensible and more usable
in the future.
Closes https://github.com/mesonbuild/meson/issues/2785
This allows for much easier cross compiler configuration for tools like
LLVM. This patch does honor the 'native' keyword, and falls back to
searching PATH if the binary name is not specified.
I'd be fine with either removing the fallback behavior, or marking it as
deprecated and removing it later.
Fixes#2921
This replaces calls to .rstrip('git'), .rstrip('svn') with a regex that
takes the leading numbers and dots, and throws away the rest. This also
moves the code up to the ConfigToolDepdency level, since these config
tools are of various quality and some of them are good, and some are
not. This shouldn't affect well behaved tools.
This should future proof LLVM against future suffixes (like someone
doing something strange like using Mercurial as a VCS).
I'm not sure this is a good idea, but at the moment it seems a bit too easy
to write something like dep.get_pkgconfig_variable('inculdedir:') (sic) and
not notice it's not doing anything useful.
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)
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.
Nirbheek Chauhan
Christopher Dunn
Nirbheek Chauhan
Marvin Scholz
FFY00
Martin Kelly
Dylan Baker
Elliott Sales de Andrade
Aleksey Filippov
Jon Turney
Edward Betts
Christophe Gouiran
Nikita Churaev