Instead use coredata.compiler_options.<machine>. This brings the cross
and native code paths closer together, since both now use that.
Command line options are interpreted just as before, for backwards
compatibility. This does introduce some funny conditionals. In the
future, I'd like to change the interpretation of command line options so
- The logic is cross-agnostic, i.e. there are no conditions affected by
`is_cross_build()`.
- Compiler args for both the build and host machines can always be
controlled by the command line.
- Compiler args for both machines can always be controlled separately.
When using pkg.generate(mylib, library : publicdep) it is pretty clear
we don't want to associate publicdep to this generated pkg-config file.
This is a small behaviour break in theory, but also fixes real bug in
the case publicdep is later used to generate another pkg-config file
that does not depend on mylib, that would write a wrong `Requires:
mylib` in the genarated pkg-config file.
This fix unavoidable deprecation warning when glib is cross built
for Android. Glib does `pkg.generate(libglib, libraries : [libintl],
...)` which wrongly associates libintl to the generated glib-2.0.pc, so
when later it generates gio-2.0.pc file that depends on libglib, it will
warn about libintl being associated with libglib. This does not happen
in normal glib build because libintl is usually provided by glibc and is
only an internal library when it fallbacks to a subproject.
This new cmake module allows to generate cmake package files. This may ease the
porting for cmake projects that are exporting cmake package informations for other
depending projects. The module uses as much as possible the templates provided by
the cmake installation (and so cmake needs to be installed).
This would normally be exposed by the ExternalProgramHolder, but wasn't
due to the implementation of the PythonInstallation module. Because of
that I've duplicated the method so that we can add the FeatureNew
decorator.
Fixes#4070
Into a generic interpreter object. This isn't a module, it's an object
returned by a module, it also happens to be a special case of an
ExternalProgram, which is a normal interpreter object. Let's treat it
like one.
Since `_process_libs` appends the lib's dependencies this list already,
the final return value of `_process_libs` will end up after its
dependencies, which is the wrong way around. (The lib must come first,
then its dependencies)
The easiest solution is to simply pre-pend the return value of
`_process_libs` rather than appending it, so that its dependencies come
after the library itself.
Closes#4091.
Windows requires things to be linked, on macOS distutils doesn't link by default.
On Linux etc. things are not so clear, some distros like Debian patch distutils to not link,
some don't. In addition the manylinux wheels spec prohibits linking against libpython
and upstream is thinking about changing the default:
https://bugs.python.org/issue34814
Call into distutils to figure out what distutils does and in case it doesn't link
against libpython replace the passed in Python dependency with a partial one.
- Add libraries from InternalDependency.libraries
- Deprecate association of libraries from the "libraries" keyword
argument to the generated pkg-config file.
If a project generates a single pc file but multiple shared libraries
with dependencies on each other, the generated pc name will be used to
generate a Requires.private dependency, which means the project will
depend on itself. This breaks at least some versions of pkg-config
(0.27 in RHEL7) which cannot handle the recursion and error out.
When adding the dependency using the pc name, check that it's not
on the project itself.
Fixes#4583
this adds support for generating pkgconfig files for c#.
The difference to c and cpp is that the -I flag is not known to the c#
compiler, but rather the -r flag which is used to link a .dll file into
the compiled library.
However this opens the question of validating which pkgconfig files can
be generated (depending on the language).
This implements 4409.
Too few arguments for string format. Format "{0} sources specified and
couldn't find {1}, please check your qt{2} installation" requires at least
3, but 2 are provided.
This alert was introduced in f7f439c a year ago
Although `gtkdoc` function has support for `c_args` argument[0], it
produces warning messages due to missing string in the permitted
arguments list.
[0] https://github.com/mesonbuild/meson/pull/4192
When dependency(), find_library(), find_program(), or
python.find_installation() return a not-found object and disabler is
true, they return a Disabler object instead.
It is possible for compiler flags to include special characters, such as
double quotes which are needed to define macros with -D options. Since
gtkdoc-scangobj uses shlex.split to split arguments passed to --cc,
--ld, --cflags, --ldflags into lists, we can safely use shlex.quote to
properly quote arguments for these options.
John Ericson
Ninja-Koala
Elliott Sales de Andrade
Nirbheek Chauhan
Xavier Claessens
Michael Hirsch, Ph.D
Sergey Shatunov
David Fort
Alistair Thomas
John Ericson
guruDanny67
Thibault Saunier
Dylan Baker
Niklas Haas
Christoph Reiter
Philippe Normand
Luca Boccassi
Marcel Hollerbach
Jon Turney
Iñigo Martínez
Olivier Crête
Jussi Pakkanen
xiannox
TingPing
Ting-Wei Lan