mingw GCC using ld.bfd emits diagnostics that include
"-plugin-opt=-pass-through=-lmoldname" and this triggers a match for
mold when it should not.
Instead, always check the very beginning of the output for the linker
id. This is pretty consistent:
- it is always on stdout
- GCC may put additional things on stderr we don't care about
- swift is bizarre and on some OSes redirects the linker stdout to
swiftc's stderr, but it will still be the only stderr; we didn't even
check stderr at all until commit 712cbe0568
For gold/bfd linkers, the linker id is always the *second* word, after
the legally mandated "GNU" we already check for.
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
...
```
- `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
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
"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 6acfe48f32, 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 01be50fdd9 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".
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.
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.
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 fb2cdd0fe2 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 0b97d58548
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#3287Closes#9761
lcov doesn't read the config file by default, but we can do the smart
thing here.
Fixes#4628
Some executable names are invalid, and while it's unlikely anyone will
specify such a thing using the --executable argument, it's not unlikely
that people experimenting will attempt to use meson init in a directory
named "test".
This then defaults to that for both the project name and the sample
target name, and the latter produces errors when you try to build it.
Fixes#10321
By default, meson will try to look for shared libraries first before
static ones. In the meson.build itself, one can use the static keyword
to control if a static library will be tried first but there's no simple
way for an end user performing a build to switch back and forth at will.
Let's cover this usecase by adding an option that allows a user to
specify if they want dependency lookups to try static or shared
libraries first. The writer of the meson.build can manually specify the
static keyword where appropriate which will override the value of this
option.
In a couple of spots, kwargs.get('static', False) was being
unneccesarily used. In these spots, we can just use self.static instead
which is already inherited from the ExternalDependency. In additional,
the python system dependency oddly has a kwargs.get('static', False)
line which overrides the self.static in that dependency for no real
reason. Delete this line too.
Some projects treat meson.project_source_root() as the root of the
dependency files, because the project itself merely wraps a bunch of
datafiles. Our validation to make sure this doesn't point to another
subproject, made use of pathlib.Path's generator for all component
paths, which... did not include the path itself. So go ahead and
explicitly check that too. Add a test case to verify it while we are at
it.
Fixes https://github.com/mesonbuild/meson/pull/10103#issuecomment-1114901033
This function can be used to add fundamental dependencies such as glib
to all build products in one fell swoop. This can be useful whenever,
due to a project's coding conventions, it is not really possible to
compile any source file without including the dependency.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Eli Schwartz