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.
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.