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.
cmake: get language from Meson project if not specified as depedency(..., langugage: ...)
deps: add threads method:cmake
dependency('threads', method: 'cmake') is useful for cmake unit tests
or those who just want to find threads using cmake.
cmake: project(... Fortran) generally also requires C language
Normally MPI programs would be run with MPI exec, but Travis-CI
has errors wanting --allow-run-as-root. To simplify, we don't use
mpiexec in this test, since it's a library check, not an MPI stack check.
Scalapack uses a library stack that can be challenging to manage.
Not least of all since many Scalapacks ship with broken / incomplete
pkg-config files and CMake FindScalapack.cmake
This resolves those issues for typical Scalapack setups including:
* Linux: Intel MKL or OpenMPI + Netlib
* MacOS: Intel MKL or OpenMPI + Netlib
* Windows: Intel MKL (OpenMPI not available on Windows)
This addresses various real-world problems with HDF5 pkg-config, including
* hdf*.pc with package versions as part of the filename
* malformed hdf*.pc missing the commonly-used HDF5 HL module
---
Additionally, this refactors more complicated dependencies such as
HDF5 and OpenMPI. This may help us deduplicate internal dependency
code in the future.
HDF5 selftest: improve platform-agnostic test
ci: init demo github action for HDF5 framework
ci Actions: hold off on MSYS2 for now [skip ci]
hdf5: ensure C libraries always included
ci: mac hdf5--use clang+gfortran
* gtkdoc: Add 'check' kwarg
This runs gtkdoc-check in meson tests.
Also reorganize the gtkdoc test because we cannot reliably build
multiple doc into the same directory. Not all files generated by gtk-doc
are prefixed with the target name.
determine_rpath_dirs() can return paths to external dependencies not
in the build dir and passing them first as a link path leads to
g-ir-scanner for example linking against the already installed library
instead of the just built one.
This was reported in g-i: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/272
and comes up quite often when a library adds some new symbols which aren't present in the
system library, which then makes linking fail.
The first place where the order is changed is _scan_gir_targets(), which looks like an unintentional
change in the refactoring in 8377ea45aa
The second place in _get_link_args() has always been that way and only the rpath order is changed,
but it looks to me as if the same rules should apply here too.
Yonggang Luo
Dylan Baker
Daniel Mensinger
Simon McVittie
cmcneish
Mike Gorse
Xavier Claessens
Nirbheek Chauhan
Jon Turney
Michael Hirsch, Ph.D
Marc
Michael Hirsch, Ph.D
Patrick Griffis
Xavier Claessens
gjaeger1
Jussi Pakkanen
Christoph Reiter