This should be done in all cases of language_stdlib_only_link_flags, but
I don't have access to all of the compilers to test it.
This is required in cases where object files created by gfortran are
linked using another compiler with a differen default search path, such
as gfortran and clang together.
This patch adds a new meson built-in option for cython, allowing it to
target C++ instead of C as the intermediate language. This can, of
course, be done on a per-target basis using the `override_options`
keyword argument, or for the entire project in the project function.
There are some things in this patch that are less than ideal. One of
them is that we have to add compilers in the build layer, but there
isn't a better place to do it because of per target override_options.
There's also some design differences between Meson and setuptools, in
that Meson only allows options on a per-target rather than a per-file
granularity.
Fixes#9015
I ran into one of these from LGTM, and it would be nice if pylint could
warn me as part of my local development process instead of waiting for
the CI to tell me.
This really is more of a struct than a dict, as the types are disjoint
and they are internally handled, (ie, not from user input). This cleans
some things up, in addition I spotted a bug in the ModuleState where the
dict with the version and license is passed to a field that expects just
the version string.
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
Again, this is not complete and is just enough for backend.py. Again,
typing these is complicated massively by the layering violations in the
Target classes and the interpreter.
This is not complete, it's just enough for backend/backend.py. A more
completely typing would be more difficult, especially whithout
untangling the layering violation between the build targets and the
interpreter.
The problem is what happens in this case:
```meson
add_project_arguments('-DHOST', language : 'c', native : false)
add_project_arguments('-DBUILD', langauge : 'c', native : true)
```
The original meson behavior was that in an host == build configuration
only the `native : false` would be applied. This doesn't really make
sense as in that case the build machine is the host machine, so it is
both the native and non-native machine at once. We changed this so that
the both would be applied in a host == build configuration, but this is
a behavioral change, and needs to be reverted.
Fixes: #9037
This commit introduces a new type of `HoldableObject`: The
`SecondLevelHolder`. The primary purpose of this class is
to handle cases where two (or more) `HoldableObject`s are
stored at the same time (with one default object). The
best (and currently only) example here is the `BothLibraries`
class.
There's no reason to allow None into the backend, it already has code to
check that all of the values of the FileMode object are None, so let's
use that, which is much simpler all the way down.
As seen in the testcase, passing objects to custom_target does not work
if headers are passed extract_objects(), or if extract_all_objects() is used
and the sources include any header files. To fix this, use the code that
already exists for unity build to filter out the nonexistent ".h.o" files.
This already gives for free the handling of genlist, which was mentioned
in a TODO comment.
For qt we already have all of the necissary checking in place. Now in
the interpreter we have the same, the intrperter does all of the
checking, then passed the arguments to the Generator initializer, which
just assigns the passed values. This is nice, neat, and clean and fixes
the layering violatino between build and interpreter.
When mutable items are stored in an lru cache, changing the returned
items changes the cached items as well. Therefore we want to ensure that
we're not mutating them. Using the ImmutableListProtocol allows mypy to
find mutations and reject them. This doesn't solve the problem of
mutable values inside the values, so you could have to do things like:
```python
ImmutableListProtocol[ImmutableListProtocol[str]]
```
or equally hacky. It can also be used for input types and acts a bit
like C's const:
```python
def foo(arg: ImmutableListProtocol[str]) -> T.List[str]:
arg[1] = 'foo' # works while running, but mypy errors
```
The build level shouldn't be deal with interpreter objects, by the time
they leave the intpreter they should be in the Meson middle layer
representaiton
Dependencies is already a large and complicated package without adding
programs to the list. This also allows us to untangle a bit of spaghetti
that we have.
All changes were created by running
"pyupgrade --py3-only --keep-percent-format"
and committing the results. I have not touched string formatting for
now.
- use set literals
- simplify .format() parameter naming
- remove __future__
- remove default "r" mode for open()
- use OSError rather than compatibility aliases
- remove stray parentheses in function(generator) scopes
Rather than having to manually build the locale aware man paths with
`install_data('foo.fr.1', install_dir: join_paths(get_option('mandir'), 'fr', 'man1'), rename: 'foo.1')`
Support doing
`install_man('foo.fr.1', locale: 'fr')`
By default all subprojects are installed. If --skip-subprojects is given
with no value only the main project is installed. If --skip-subprojects
is given with a value, it should be a coma separated list of subprojects
to skip and all others will be installed.
Fixes: #2550.
Re-implement it in backend using the same code path as for
custom_target(). This for example handle setting PATH on Windows when
command is an executable.
This new keyword argument makes it possible to run specific
test setups only on a subset of the tests. For example, to
mark some tests as slow and avoid running them by default:
add_test_setup('quick', exclude_suites: ['slow'], is_default: true)
add_test_setup('slow')
It will then be possible to run the slow tests with either
`meson test --setup slow` or `meson test --suite slow`.
Add function to Build class to get targets of type BuildTarget
Update xcode backend to call get_build_targets when iterating over targets.
This resolves crash in xcode backend when using custom targets:
AttributeError: ‘CustomTarget’ object has no attribute ‘objects’
On Windows this would fail because of missing DLL:
```
mylib = library(...)
exe = executable(..., link_with: mylib)
meson.add_install_script(exe)
```
The reason is on Windows we cannot rely on rpath to find libraries from
build directory, they are searched in $PATH. We already have all that
mechanism in place for custom_target() using ExecutableSerialisation
class, so reuse it for install/dist/postconf scripts too.
This has bonus side effect to also use exe_wrapper for those scripts.
Fixes: #8187
There are still caveats here. Rust/cargo handles generated sources by
writing out all targets of a single repo into a single output directory,
setting a path to that via a build-time environment variable, and then
include those files via a set of functions and macros. Meson's build
layout is naturally different, and ninja makes working with environment
variables at compile time difficult.
Fixes#8157
we have two functions to do the exact same thing, and they're basically
implemented the same way. Instead, let's just use the BuildTarget one,
as it's more generally available.
Currently InstallDir is part of the interpreter, and is an Interpreter
object, which is then put in the Build object. This is a layering
violation, the interperter should have a Holder for build data. This
patch fixes that.
This patches takes the options work to it's logical conclusion: A single
flat dictionary of OptionKey: UserOptions. This allows us to simplify a
large number of cases, as we don't need to check if an option is in this
dict or that one (or any of 5 or 6, actually).
I would have prefered to do these seperatately, but they are combined in
some cases, so it was much easier to convert them together.
this eliminates the builtins_per_machine dict, as it's duplicated with
the OptionKey's machine parameter.
This was all layering violations before. Now we have Headers in the
build module, and a holder in the interpreter. All of the type
validation is done in interpreter method for `install_headers`.
So that editors that can fold code (vim, vscode, etc) can correctly fold
functions, instead of getting confused by code that doesn't follow the
current indention. Also, it makes the code easier to read.
The deprecation message for "gui_app" is appearing for every target
rather than just once, and even if the required version is older
than 0.56.0. Use @FeatureDeprecatedKwargs to fix both issues.
If static_library is used as a convenience library (e.g. for link_whole)
it should in principle not need position independent code.
However, if the executables that the libraries is linked to are PIE,
the non-PIC objects in the static library will cause linker errors.
To avoid this, obey b_pie for static libraries if either b_staticpic=false
or they use "pic: false".
Without this patch, QEMU cannot use b_staticpic, which causes a slowdown
on some QEMU benchmarks up to 20%.
extract_objects is repeatedly looking up files in self.sources, which is a list.
Convert it to a set beforehand so that the lookup is O(1).
On a QEMU build, the time spent in extract_objects goes from 3.292s to 0.431s.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This gives the version that the feature was deprecated in, and doesn't
print the warning if the project supports versions of meson in which the
project wasn't deprecated.
in tree like dep structures with a lot of source: declarations, this can
result in a lot of presure on the source list. this saves ~3s out of 7s
in the interpretor stage in efl build.
Generally, we'd want to use str() rather than repr() in error messages
anyhow, as that explicitly gives something designed to be read by
humans.
Sometimes {!r} is being used as a shortcut to avoid writing the quotes
in '{!s}'.
Unfortunately, these things aren't quite the same, as the repr of a
string containing '\' (the path separator on Windows) will have those
escaped.
We don't have a good string representation to use for the arbitrary
internal object used as an argument for install_data() when it's neither
a string nor file (which doesn't lead to a good error message), so drop
that for the moment.
If the feature hadn't been broken in the first place it would have
worked on them anyway, so we might as well expose it. I'm loathe to do
it because one of the best features of meson in a mixed C/C++ code base
is that meson figures out the right linker every time, but there are
cases people have where they want to force a linker. We'll let them keep
the pieces.
Currently it does nothing, as the field is read too late, and additional
languages have already been considered. As such if the language
requested is closer to C (for example you want C but have a C++ source
with only extern C functions) then link_langauge is ignored.
Fixes#6453
A current rather untyped storage of options is one of the things that
contributes to the options code being so complex. This takes a small
step in synching down by storing the compiler options in dicts per
language.
Future work might be replacing the langauge strings with an enum, and
defaultdict with a custom struct, just like `PerMachine` and
`MachineChoice`.
Adjust the handling of a name_prefix: [] kwarg to be the same as
name_suffix: [] kwarg, i.e. identically to the case where it's omitted,
so BuildTarget.prefix doesn't get set (so the default is used).
Also clarify the error reported when a non-empty list is used.
Similar to meson.override_find_program() but overrides the result of the
dependency() function.
Also ensure that dependency() always returns the same result when
looking for the same dependency, this fixes cases where parts of the
project could be using a system library and other parts use the library
provided by a subproject.
This makes the typing annotations basically impossible to get right, but
if we only have one key then it's easy. Fortunately python provides
comprehensions, so we don't even need the ability to pass multiple keys,
we can just [extract_as_list(kwargs, c) for c in ('a', 'b', 'c')] and
get the same result.
listify shouldn't be unholdering, it's a function to turn scalar values
into lists, or flatten lists. Having a separate function is clearer,
easier to understand, and can be run recursively if necessary.
This gives consistent reporting of this error for all platforms.
Also, reporting this error when constructing the BuildTarget, rather
than discovering the problem during backend generation means that the
error is reported against with a location.
declare_dependencies
This allows dependencies declared in subprojects to set variables, and
for those variables to be accessed via the get_variable method, just
like those from pkg-config and cmake. This makes it easier to use
projects from subprojects in a polymorphic manner, lowering the
distinction between a subproject and an external dependency every
further.
There are three problems:
1) Dunders like `__lt__` and `__gt__` don't return bool, they return
either a bool or the NotImplemented singleton to signal that they don't
know how to be compared.
2) The don't take type object, the take `typing.Any`
3) They need to return NotImplemented if the comparison is not
implemented, this allows python to try the inverse dunder from the
other object. If that object returns NotImplemented as well a
TypeError is raised.
t.pic won't be defined. We can only hope it has been built with -fPIC.
Linker will complain otherwise any way.
t.extract_all_objects_recurse() won't be defined. We could support this
case by extracting the archive somewhere and pick object files.
Some things, like `method[...](...)` or `x: ... = ...` python 3.5
doesn't support, so I made a comment instead with the intention that it
can someday be made into a real annotation.
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
This function is currently setup with keyword arguments defaulting to
None. However, it is never called without passing all of it's arguments
explicitly, and only one of it's arguments would actually be valid as
None. So just drop that, and make them all positional. And annotate
them.
Some things, like `method[...](...)` or `x: ... = ...` python 3.5
doesn't support, so I made a comment instead with the intention that it
can someday be made into a real annotation.
Daniel Mensinger