Ideally we wouldn't need to have the default dict here and could just
rely on it being set as soon as project is called. There is a corner
case exercised by test case common/35 run program, which is that if a
FeatureNew or FeatureDeprecated is called to generate the meson version
it will be unset, to work around this I've changed the type from a dict
to a default dict with '' as the default value.
A better fix would probably be to store all of the
FeatureNew/FeatureDeprecated checks until the end, then evaluate them,
but for now this results in no loss of functionality, only more
functionality, even if it isn't prefect.
This gives the version that the feature was deprecated in, and doesn't
print the warning if the project supports versions of meson in which the
project wasn't deprecated.
The implementation of this function has changed enough that the name
doesn't really reflect what it actually does. It basically returns true
unless you're cross compiling, need and exe_wrapper, and don't have one.
The original function remains but is marked as deprecated.
This makes one small change the meson source language, which is that it
defines that can_run_host_binaries will return true in build == host
compilation, which was the behavior that already existed. Previously
this was undefined in build == host compilation.
This revert a part of #7020 because it was using gir_inc_dirs
before it is set. Properly fix typelib_includes instead that was working
only when g-i is a pkgconfig dependency.
```
File "mesonbuild/cmake/interpreter.py", line 293, in postprocess
'Unknown {}_std "{}" -> Ingoring. Try setting the project'
IndexError: Replacement index 2 out of range for positional args tuple
```
Now follows ios and other platform directory layouts. Moves from
separate android_$arch directories to every library containing a _$arch
suffix. e.g. libQt5Core_x86.a in a single directory.
in tree like dep structures with a lot of source: declarations, this can
result in a lot of presure on the source list. this saves ~3s out of 7s
in the interpretor stage in efl build.
has_function() tries to link an example program using the function
to see if it is available, but with clang on 64bit Windows this
example always already failed at the compile step:
error: cast from pointer to smaller type 'long' loses information
long b = (long) a;
This is due to long!=pointer with LLP64
Change from "long" to "long long" which is min 64bit and should always
fit a pointer. While "long long" is strictly a C99 feature every
non super ancient compiler should still support it.
Currently deprecation features use the same logic as new features, but
that doesn't work correctly. FeatureNew wants to warn about cases where
you claim to support >= 0.40, but use a feature from 0.42; deprecation
wants to warn when you claim to support >= 0.50, but use a feature that
was replaced in 0.45.
To make this work we need to invert the version check in the deprecation
function, so that if the deprecation is 0.45, and the supported version
is >= 0.50, we get a true not a false.
Currently The Deprecated and New features checkers share an attribute
through a base class that should be per class. We need to duplicate this
and move it into each of the sublcasses
Fixes#7080
The system tool is always the wrong thing to use and cause hard to debug
issues when trying to link system libraries with cross built binaries.
The ExternalDependency base class already had a method to deal with
this, used by PkgConfigDependency and QtBaseDependency, so it should
make things more consistent.
The builtin check had a special case that if a header was provided and
the function wasn't defined, it would ignore the builtin to avoid
non-functional builtins (for example __builtin_posix_memalign in MSYS2).
GCC 10 gained support for __has_builtin() which now skipps this check
and because __has_builtin(__builtin_posix_memalign) returns true the
non functional builtin is now reported as available.
To get the old behaviour back move the special case in front of the actual
availability check.
Fixes#7113
As stated by the doc, default to install python sources to purelib
location, as they should not depend on platform.
This also fixes discrepancy between get_install_dir() and
install_sources() locations.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Discussions in #6524 have shown that there are various possible uses of the
kconfig module and even disagreements in the exact file format between
Python-based kconfiglib and the tools in Linux. Instead of trying to
reconcile them, just rename the module to something less suggestive and
leave any policy to meson.build files.
In the future it may be possible to add some kind of parsing through
keyword arguments such as bool_true, quoted_strings, etc. and possibly
creation of key-value lists too. For now, configuration_data objects
provide an easy way to access quoted strings. Note that Kconfig stores
false as "absent" so it was already necessary to write "x.has_key('abc')"
rather than the more compact "x['abc']". Therefore, having to use
configuration_data does not make things much more verbose.
The comment for this code is correct, but the code itself isn't. The way
it's implemented in a cross compile we don't look at PKG_CONFIG_PATH at
all.
Fixes: #7062
Gtest can output junit results with a command line switch. We can parse
this to get more detailed results than the returncode, and put those in
our own Junit output. We basically just throw away the top level
'testsuites' object, then fixup the names of the tests, and shove that
into our junit.
Dylan Baker
Xavier Claessens
Nirbheek Chauhan
Matthew Waters
Daniel Mensinger
Marcel Hollerbach
Eric Lemanissier
Ole André Vadla Ravnås
Christoph Reiter
Jussi Pakkanen
Marc-André Lureau
Andrei Alexeyev
Szabi Tolnai
Reza Housseini
Paolo Bonzini
Wenjian He
James Hilliard
Eric Engestrom
GustavoLCR
Michael Brockus