It should build the fallback subprject with default_library=static and
override the dependency for both static=True and static kwarg not given.
Fixes: #8050.
Explicitly mention that the project definition is invalid, and clarify
that project is `project()` -- a function.
Also try to walk the directory tree upward, and if there are parent
meson.build files, just say this isn't the project root, and "maybe you
meant to run meson there instead?"
This won't catch calls to subdir('foo/bar') but we can't be perfect,
only better than before and catch the *majority* of such cases, and
hopefully it's a lot more clear if meson protests that the project is
"invalid, there is no project() function", where the user should look
for a potential solution.
Fixes#3426
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.
In the case main->subp->subsubp, if subsubp succeed to configure but
subp subsequentially fails, subsubp is still being built but its summary
was missing.
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
Sonarcloud.io only can read the sonarqube based report that gcovr can
produce. This change enables support for this output in meson and
ninja.
Signed-off-by: Weston Schmidt <Weston_Schmidt@alumni.purdue.edu>
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.)
This is useful both from the perspective of optional functionality that
requires a module, and also as I continue to progress with Meson++,
which will probably not implement all of the modules that Meson itself
does.