| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
We accept boolean false to indicate "do not install this one particular
output", but the type checking simply checked if it is a bool. We do
this correctly for configure_file, so copy the same validator from
there.
|
|
This fixes bogus messages "skipped: feature foo disabled" when
auto_features=disabled. It was reporting the name of the latest
get_option() call instead of the name of the current feature option.
This is especially visible in GStreamer summary where it should show a
different option name for every subproject but instead shows "tools"
everywhere:
```
Subprojects
gst-devtools : NO Feature 'tools' disabled
gst-editing-services : NO Feature 'tools' disabled
...
```
|
|
Which also fixes builds on windows that might produce a .lib instead of
a .a. The error message has been changed to reflect that as well
|
|
Including that we don't accept SharedLibraries or CustomTarget[Index]s
that are a shared library
|
|
This is useful for cases where we treat CustomTargets as linkable
targets, and need to know whether they're going to link statically or
dynamically.
|
|
Since a SharedLibrary can't be statically linked in, we shouldn't allow
the method to complete.
|
|
|
|
- `BuildTarget` should be `SharedLibrary | StaticLibrary`
- Needs to take `CustomTargetIndex` as well as `CustomTarget`
- don't assign to self until values have been converted to the correct
type
|
|
which do not hold BuildTargets, they are `SharedLibrary | StaticLibrary |
CustomTarget | CustomTargetIndex` (whole doesn't accept `SharedLIbrary`)
|
|
|
|
That come to light with some of the changes later in this series,
particularly around dependencies.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Change message
Header <foo.h> has symbol "BAR"
to
Header "foo.h" has symbol "BAR"
with the first part also now in bold. This is more consistent with
other messages like
Has header "foo.h"
and
Checking whether type "foo" has member "bar"
|
|
We were poking directly at the node, so if it was a FunctionNode then
this broke. Instead, just do a reverse lookup in the overrides table to
get the original find_program name.
|
|
TAP version 14 introduced subtests, that are supposedly backward compatible
because "TAP13 specifies that non-TAP output should be ignored". Meson
reported TAP syntax errors based on behavior of "prove" at the time,
but it seems that now "prove" has become a lot more lenient; it even
accepts the following completely bogus input just fine:
---
ok 1
ok 2
x
1..1
---
So do the same and make Meson's parser accept invalid TAP input silently.
Fixes: #10032
|
|
|
|
As we commonly do in other modules
|
|
Which doesn't have `StructuredSources`, as is actually quite common.
|
|
|
|
|
|
|
|
In commit f2d21bf8a98fe4eb528a077f3faf5d68cd35c244 a type annotation was
added that does not exist. The referenced type is present but only as a
dotted name.
|
|
- mismatched method type
- mismatched parameter names
|
|
|
|
|
|
"targetting" is verb-derived adjective, which sort-of-works here, but
makes the whole sentence awkward, because there's no verb. Let's just
use present simple.
|
|
"tried to use" implies that the attempt was not successful, i.e. that meson
ignored the feature. But that is not what happens, apart from the warning the
feature works just fine. The new message is also shorter ;)
|
|
|
|
In commit 6acfe48f32110671a0adf80ad3497a35105b265d, the kwarg was added
to environment() in addition to the env object methods. As part of the
associated refactor, a shared KwargInfo was used, and evolved to be new
since 0.62.0 in the two cases where it is in fact new.
However, it *also* set the base KwargInfo for the exact same newness,
which is wrong as it was present ever since the initial introduction in
0.34.0
As usual for anything that predates 0.37.0 we simply don't tag
FeatureNew. Revert this back to the same KwargInfo definition from
before the refactoring commit.
Fixes #10402
|
|
This was added in commit 01be50fdd90851f17de5499537f10b5b62c9fb49 with
zero explanation as a side effect of moving code around. It seems like a
really bad idea and it causes people to view debugging Meson projects on
e.g. debuginfod systems as "painful".
|
|
Qt offers a tool to automatize most of what needs to be done regarding its libraries.
|
|
Compress files under source directory using Deflate method.
By default, files are not compressed in the archive.
Compression is active only when this option is defined.
https://docs.python.org/3/library/zipapp.html?highlight=zipapp#cmdoption-zipapp-c
|
|
Previously, any value other than `windows` or `console` caused an
exception. This change allows for `efi_application` to be passed as
the `win_subsystem` to MinGW based linkers.
|
|
Older versions are not supported by the cmake module since 0.62.
This avoids having to hard-code the linux-bionic-gcc CI job as being
unable to run these tests, which leaves other older environments like
Debian 10 still trying to run them (and failing).
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
If we encounter a file under the Boost library directory that doesn't
look like a Boost library binary, we should ignore it.
We log a warning for each file we ignore, except for ones we know are
safe to ignore (e. g. PDB files from the SourceForge Windows
distribution). This should avoid polluting the log.
Fixes #8325.
|
|
python compiled extensions should never need to expose any symbol other
than PyInit_* which is declared with default visibility via
PyMODINIT_FUNC on supported compilers.
Thus, a reasonably sane default is to mark any other symbols as hidden,
while still respecting any manually specified visibility.
Gate this on the version of python itself, as not all versions decorate
PyMODINIT_FUNC properly.
|
|
compilers
This option is only valid for C++ and ObjC++, but the kwarg is useful
for mixed language targets. Asking for inlines as well, when the
compiler driver is trying to build the C components of a target, results
in gcc emitting:
```
cc1: warning: command-line option ‘-fvisibility-inlines-hidden’ is valid for C++/ObjC++ but not for C
```
Squelch this warning by filtering it out on Meson's side of things.
|
|
In commit fb2cdd0fe2797b30e1fd4c118407302402739a3b the internal property
was renamed, but one use case of it in raising a MesonException was not
changed to go with it.
This meant that instead of erroring out with:
```
ERROR: GNU symbol visibility arg XXXX not one of: default, internal, hidden, protected, inlineshidden
```
we instead errored out with:
```
AttributeError: 'SharedLibrary' object has no attribute 'symbol_visibility'
```
Fixes #9659
|
|
Otherwise it always returns the value for c++98, starting with MSVC 2017
15.7 or later. Earlier versions are not affected by this mis-feature.
See: https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-160
This was originally applied as 0b97d585480e973d8b149618901f7a4ddfa1a906
but later reverted because it made the CI red. Try it again, now.
Original-patch-by: Dylan Baker <dylan@pnwbakers.com>
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
|
|
|
|
|
|
|
|
gcovr will read this file anyway, but if it exists we don't need to
assume that the project wishes to exclude subprojects/ -- they can
determine that themselves.
Fixes #3287
Closes #9761
lcov doesn't read the config file by default, but we can do the smart
thing here.
Fixes #4628
|
|
Further work pending GCC bug #105467 and/or Ninja bug #1962.
|
|
|
