- vcpkg libraries are not found when given cmake_toolchain_file and vcpkg_target_triplet as cmake_args when looking for the dependency if the first call to cmake has different arguments. The libraries are found if the first call has same arguments or if the CMakeCache.txt is deleted in call_with_fake_build.
Since we parse buildoptions.json to pass options, we end up passing
-Dbuildtype and also -Doptimization and -Ddebug which triggers the
warning:
WARNING: Recommend using either -Dbuildtype or -Doptimization + -Ddebug [...]
Filter out buildtype. It is redundant.
Causes spammy warnings from the linker:
ld: warning: -headerpad_max_install_names is ignored when used with -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES)
When meson is currently being run with a python that seems to have been
installed from the Windows Store, replace the general WindowsApps
directory in search paths with dirname(sys.executable), and also handle
failures with pathlib.resolve on WindowsApps exe files.
This is especially useful for Conan, where only the boost.pc
file is provided and manually setting BOOST_ROOT is not a
good solution since it is in a private cache directory.
See #5438
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 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
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