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.
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
This was already skipped when running on the Ubuntu 18.04 version of gcc,
but it also fails with gcc 8.3.0 on Debian 10. Instead of hard-coding
specific versions to look for, do a version comparison.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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
Test that add_project_dependencies() can only be used before build targets
have been declared. Also test that one cannot use override_dependency
on a superproject to inject a superproject's build products into the
subproject. This would violate the rule that build products cannot be used
with add_project_dependencies() (similar to e.g. compiler.has_function),
so check that meson detects the situation correctly.
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>
Extract to a separate function the code that resolves dependencies
for compiler methods. We will reuse it for add_project_dependencies().
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Both dependencies.ExternalLibrary and dependencies.InternalDependency are
subclasses of dependencies.Dependency, no need to list them separately.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In the original RefMan 2.0 implementation, the types for this were
filled in as `str | file`, but the code only ever accepted the former.
Fix the documentation so that it aligns with reality.
Fixes#10338
This handles various edge cases:
- checks for sandbox violations just like all other functions
- warn for direntry issues
- check for generated files referred to via strings instead of the
returned object
(All valid use cases for wanting to sneak around the checks, are made to
work via commit bba588d8b03a9125bf5c4faaad31b70d39242b68.)
On Python 3.8.x and later, if the imported module requires non-system DLLs that
are not installed nor bundled with the module package, os.add_dll_directory()
must be called on every path that contains the required DLLs, so that the module
can be imported successfully by Python.
Make things easier for people by calling os.add_dll_directory() on the
valid directories in %PATH%, so that such module checks can be carried out
successfully with much less manual intervention.
+ Extend the parser to recognize the multiline f-strings, which the
documentation already implies will work.
The syntax is like:
```
x = 'hello'
y = 'world'
msg = f'''This is a multiline string.
Sending a message: '@x@ @y@'
'''
```
which produces:
```
This is a multiline string.
Sending a message: 'hello world'
```
+ Added some f-string tests cases to "62 string arithmetic" to exercise
the new behavior.
Move GlobalState to a runtime T.NamedTuple, use it for constructing the
tuple we are passing around rather than expecting mypy to detect that
the one we already have matches.
We need to setup the environment we pass to g-ir-scanner because it will
try to use pkg-config to find dependencies, and that must respect user
settings from machine file. Also make it use uninstalled pc files Meson
generated in the case dependencies, such as glib, have been built as
subproject.
The new get_env() method that returns an EnvironmentVariables object
will be needed in next commit that will pass it to CustomTarget.
This has the side effect to use the proper os specific path separator
instead of hardcoding `:`. It is the obvious right thing to do here, but
has caused issues in the past. Hopefully issues have been fixed in the
meantime. If not, better deal with fallouts than keep doing the wrong
thing forever.
[why]
Support for the relatively new mold linker is missing. If someone wants
to use mold as linker `LDFLAGS="-B/path/to/mold"` has to be added instead
of the usual `CC_LD=mold meson ...` or `CXX_LD=mold meson ...`.
[how]
Allow `mold' as linker for clang and newer GCC versions (that versions
that have support).
The error message can be a bit off, because it is generic for all GNU
like compilers, but I guess that is ok. (i.e. 'mold' is not listed as
possible linker, even if it would be possible for the given compiler.)
[note]
GCC Version 12.0.1 is not sufficient to say `mold` is supported. The
expected release with support will be 12.1.0.
On the other hand people that use the un-released 12.0.1 will probably
have built it from trunk. Allowing 12.0.1 is helping bleeding edge
developers to use mold in Meson already now.
Fixes: #9072
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Regression in commit 11f9638035. When
`install: true` the install_dir must be set. The CustomTarget
initializer no longer checks this for us, so we must include the check
ourselves.
Regression in commit 11f9638035. We expect
exactly one string as an install_dir, but CustomTarget started expecting
it to be a list. So we need to pass it as such when forwarding
compile_translations() arguments to the CustomTarget initializer.
Nothing elaborate, just laying down the ground rules for expected usage
and pointing out that it now works. The idea is not to give people
ideas, but to let projects which already have this use case, use it with
confidence.
joshcangit
Lens
Simon McVittie
fghzxm
Eli Schwartz
Jussi Pakkanen
Khairul Azhar Kasmiran
Xavier Claessens
Dudemanguy
Paolo Bonzini
Remi Thebault
Chun-wei Fan
Daniel Mensinger
Peter Lesslie
Maple
zxey
Fini Jastrow
Ferdinand Thiessen