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>
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>
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.
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.
The compiler flag only exists on Visual Studio 2015 or later, or clang-cl,
and using this always can interfere with compiler feature detection when
this flag is not supported.
So, remove '/utf-8' from always_args if we are on Visual Studio 2013 or
earlier.
This way, we can ensure that gtk-doc parses the --path argument
correctly when passed in from the cmd.exe console, since ':' is normally
used to denote that a drive is being used on local paths.
If set to true it will generate the pkgconfig files as relocatable i.e
the prefix variable will be relative to the install_dir. By default
this is false.
Will generate a MesonException if the pkgconfig file is installed
outside of the package and pkgconfig.relocatable=true.
We can immediately short-circuit if there is no destdir, as we simply
return the prefix unchanged.
If there is some kind of destdir and the prefix contains a drive letter,
then no matter what we need to remove the drive letter before joining.
Technically, if the destdir is a relative path e.g. `destdir\` and
`C:\prefix`, we should still install to `destdir\prefix` without the
drive letter.
But... we also guarantee that destdir is an absolute path (or empty)
anyway. And even if we didn't, non-absolute destdir is a broken concept
for a variety of complicated reasons. So none of this matters in
practice.
One way or another, we don't need to actually check whether destdir is
an absolute path before cutting off the prefix drive letter.
In commit f291b637b1 the tools were moved
around but a comment got forgotten. Now, in order to be meaningful and
remind us of anything, it needs to be in a different location.