Previously the meson test case would only test boost-python on linux.
With the #7909 it is now possible to use boost-python on macOS/homebrew.
This enables the boost-python test on both linux and macOS.
It also uses python.extension_module() instead of shared_library to make the
python extension module.
This adds the noyywrap option so flex doesn't wait for more input once
we reached EOF. This also adds the nounput and noinput options to fix
compilation warnings.
We can now run the test as expected.
This does two things:
* allows the library files to be symlinks
* searches `lib` and `lib64` in `BOOST_ROOT` even if it finds lib
directories from the compiler
The first condition is needed for the homebrew on macOS because boost and boost
python are provided in seperate packages and are put together in /usr/local/lib
with symlinks to the library files. The both conditions are needed for high
performace computing environments where dependencies are often provided in
nonstandard directories with symlinks
A test case was added which looks for boost libraries in seperate directories
which have been symlinked to BOOST_ROOT/lib
The build_machine.system() value we should be matching against is
'darwin', not 'macos', so this was expected to skip everywhere.
Unfortunately, fixing this reveals that this test skips in our macos CI
runs also, (I think) because brew doesn't (normally) provide frameworks,
just pkgconfig files.
So, also skip this test there, which means it doesn't run anywhere in
CI currently.
Remove hard-coded framework test skip logic in skippable(), instead
annotate test.json with environments in which skip is expected.
(Mainly this is done with by testing the value of MESON_CI_JOBNAME now
set for linux jobs)
If the required LLVM modules can't be found, skip the LLVM framework
test, rather than succesfully doing nothing.
(This optionality is a leftover from before #7379)
(At the moment, OpenSuse provides dynamic-only LLVM. The cmake method
still finds LLVM, when a static LLVM is requested, but fails to find any
modules. This might be a bug in the cmake method of the LLVM
dependency.)
I guess the intent was that tests of thread/debug library variants only
get run with MSVC, but currently this test isn't getting run at all in
our Windows CI (since boost got removed from the VM image [1], and we
didn't notice, more on which anon).
[1] https://github.com/actions/virtual-environments/pull/2843
Tests that we find something sensible for intl, capable of producing
binaries using gettext() to translate stuff.
No more need to manually check headers and *maybe* include the intl
library, which we were doing before; the new dependency actually
simplifies the existing test, and should simplify users' build files
too...
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.
Xavier Claessens
Kevin Meagher
Eli Schwartz
Jussi Pakkanen
Adrien Plazas
Jon Turney
Daniel Mensinger
Dylan Baker
Luca Weiss
Philip Withnall
Sam Thursfield
Yonggang Luo
Simon McVittie
cmcneish
Mike Gorse