It used to support:
- a single string
- an array of anything
And as long as CustomTarget supported it too, everything worked fine.
So, a `files('foo')` worked but a `files('foo')[0]` did not, which is
silly... and it's not exactly terrible to use files() here, the input is
literally a list of source files.
Fixes building gnome-terminal
Fixes#9827
Test updated by Nirbheek Chauhan <nirbheek@centricular.com>
check: true is needed for an actual regression test, but that requires
a pedantically correct gtk-doc configuration, which I attempted to do
and failed. So let's just put check: false so we get *some* coverage:
just that typed_kwargs accepts the argument.
Related to https://github.com/mesonbuild/meson/pull/9807
Use a proper install option for this. Now `install_<type>` can directly
override `install` instead of passing a boolean to the string kwarg
`install_dir_<type>`.
generate_gir forces building both the typelib and gir, and some people
only want one or the other (probably only the typelib?) which means
flagging the other as install_dir: false in the same way custom_target
supports.
As this always worked, albeit undocumented, make sure it keeps working.
It's pretty reasonable to allow, anyway.
Fixes https://github.com/mesonbuild/meson/pull/9484#issuecomment-980131791
The `mkenums` functions can have this unset if, and only if, the
c file only variant is called. Due to side effects if the header file is
generated then `install_dir` is ensured to be set for the c file. I have
removed this side effect so that our tests actually cover this case.
Fixes#9472
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
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.
Eli Schwartz
Nirbheek Chauhan
Pablo Correa Gómez
Jon Turney
Volker Weißmann
Dylan Baker
makise-homura
Xavier Claessens
Kevin Meagher
Jussi Pakkanen
Adrien Plazas
Daniel Mensinger
Luca Weiss
Philip Withnall
Sam Thursfield
Yonggang Luo