We need to pass any generated sources down the CustomTarget
inititalizers so that they will generate a dependency correctly,
otherwise we get race conditions.
install_scripts used to replace @BUILD_ROOT@ and @SOURCE_ROOT@ but it
was not documented and got removed in Meson 0.58.0. gnome.gtkdoc() was
relying on that behaviour, but it has always been broken in the case the
source or build directory contains spaces.
Fix this by changing get_include_args() to substitue paths directly
which will then get escaped correctly.
Add a unit test that builds GObject documentation which is where this
issue has been spotted.
Fixes: #8744
Currently the Qt Dependencies still use the old "combined" method for
dependencies with multiple ways to be found. This is problematic as it
means that `get_variable()` and friends don't work, as the dependency
can't implement any of those methods. The correct solution is to make
use of multiple Dependency instances, and a factory to tie them
together. This does that.
To handle QMake, I've leveraged the existing config-tool mechanism,
which allows us to save a good deal of code, and use well tested code
instead of rolling more of our own code.
The one thing this doesn't do, but we probably should, is expose the
macOS ExtraFrameworks directly, instead of forcing them to be found
through QMake. That is a problem for another series, and someone who
cares more about macOS than I do.
See https://gitlab.gnome.org/GNOME/glib/-/issues/600
`volatile` was previously mistakenly used in GLib to indicate that a
variable was accessed atomically or otherwise multi-threaded. It’s not
meant for that, and up to date compilers (like gcc-11) will rightly warn
about it.
Drop the `volatile` qualifiers.
Based on a patch by Jeff Law.
See also http://isvolatileusefulwiththreads.in/c/.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
* depenencies/llvm: Handle llvm-config --shared-mode failing
Fixes: #7371Fixes: #7878
* test cases/llvm: Refactor to use test.json
Instead of trying to cover everything internally
There are two cases that won't work (these are taken from fortran/9
cpp), using gfortran with a non-gcc compiler on windows, or using
gfortran with apple clang. The latter is due to default search paths,
which we can fix, but is out of scope for this MR.
This is useful for automatically generated docs (doxygen, hotdoc)
with a lot of generated files that may differ with different
versions of the generator.
Since upgrading Boost to version 1.73, this test segfaults on macOS
when dynamically linked. Disable it to keep the rest of the CI
reliable.
Mitigates: #7535
Signed-off-by: Simon McVittie <smcv@debian.org>
* Add boost_root support to properties files
This commit implements `boost_root`, `boost_includedir`, and
`boost_librarydir` variable support to native and cross properties
files. The search order is currently environment variables, then
these variables, and finally a platform-dependent search.
* Add preliminary boost_root / boost_includedir tests
Each test contains a fake "version.hpp", as that's how boost detection is
currently being done. We look for this file relative to the root directory,
which probably shouldn't be allowed (it previously was for BOOST_LIBRARYDIR
but not for BOOST_ROOT). It also cannot help with breakage detection in
libraries, however it looks like this wasn't getting tested beforehand.
I've given the two unique version numbers that shouldn't be present in any
stock version of boost (001 and 002).
* Add return type to detect_split_root
* Return empty list when nothing found in BOOST_ROOT, rather than None
* Update boost_root tests
* Create nativefile.ini based on location of run_project_tests.py
* Add fake libraries to ensure boost_librarydir is being used
* Require all search paths for boost to be absolute
* Redo boost search ordering
To better match things like pkg-config, we now look through native/cross files,
then environment variables, then system locations for boost installations.
Path detection does not fall back from one method to the next for properties or
environment variables--if boost_root, boost_librarydir, or boost_includedir is
specified, they must be sufficient to find boost. Likewise for BOOST_ROOT and
friends. pkg-config detection is still optional falling back to system-wide
detection, for Conan.
(Also, fix a typo in test 33's nativefile)
* Correct return type for detect_roots
* Correct boost dependency search order in documentation
* Print debug information for boost library finding, to resolve CI issues
* Handle native/cross file templates in a more consistent way
All tests can now create a `nativefile.ini.in` if they need to use some
parameter that the testing framework knows about but they can't.
* Pass str--rather than PosixPath--to os.path.exists, for Python35
* Look for boost minor versions, rather than boost patch versions in test cases
* Drop fake dylib versions of boost_regex
* Prefer get_env_var to use of os.environ
* Correct error reporting for relative BOOST_ROOT paths
* Bump version this appears in. Also, change "properties file" to "machine file" as that appears to be the more common language.
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
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.
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.
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.
* xenial doesn't ship many dependencies, so make them all optional
since we don't guarantee that everything will work
* cmake/{5,6}: needs stdlib.h for EXIT_SUCCESS on GCC 5
* common/222: needs C++11, and GCC 5 doesn't understand `auto`
correctly unless we explicitly enable it.
* frameworks/1 boost: xenial doesn't ship boost_python3, so make it
properly optional
* frameworks/6 gettext: gettext can be installed without xgettext,
which doesn't cause the project to fail, but the installed files
list is different which causes the test to fail.
* frameworks/7 gnome: gobject-introspection can't be enabled because
the sanitizer unit test detects leaks in glib and fails
Make the 'framework/4 qt' test more flexible about what version of Qt is
expected to be present in the CI environment. Currently, this is
hard-coded as Qt5. We add an option to specify it so we can run this
test under CI with just Qt4 present.
fixes#6096.
Didn't use CMake because Curses is a real corner-case for CMake that
would require Curses-specific enhancements to Meson's CMake interface.
Dylan Baker
Jon Turney
Xavier Claessens
Jussi Pakkanen
Luca Weiss
Philip Withnall
Sam Thursfield
Yonggang Luo
Daniel Mensinger
Simon McVittie
cmcneish
Mike Gorse
Nirbheek Chauhan
Michael Hirsch, Ph.D