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.
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.
- Documentation for the pkgconfig.relocatable module option in
Builtin-options. Gives an explanation on what it does, usefulness and
what error that can occur when using it.
- Add pkgconfig.relocatable release snippet. Similar to the
documentation in Builtin-options. Just a bit more brief.
- Add Pkgconfig to DataTests.test_builtin_options_documented in the
docs unit tests.
Jussi Pakkanen
Simon McVittie
Eli Schwartz
Dudemanguy
Xavier Claessens
Paolo Bonzini
Remi Thebault
Chun-wei Fan
Daniel Mensinger
Peter Lesslie
Maple
zxey
Fini Jastrow
Ferdinand Thiessen
Simon Arlott
Kirill Isakov
Thomas Klausner
Fredrik Salomonsson