Machine files already supports `+` operator as an implementation detail,
since it's using eval(). Now make it an officially supported feature and
add a way to define constants that are used while evaluating an entry
value.
The documentation of gnome.generate_gir() has duplicated entry for
dependencies parameter. As a fix, this patch removes the entry added
recently.
Fixes: 893d101fff ("gnome: Add header kwarg to generate_gir()")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Should be "sources" not "source"
```
../meson.build:162: WARNING: Passed invalid keyword argument "source".
WARNING: This will become a hard error in the future.
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/mesonbuild/mesonmain.py", line 131, in run
return options.run_func(options)
File "/usr/local/lib/python3.7/site-packages/mesonbuild/msetup.py", line 245, in run
app.generate()
File "/usr/local/lib/python3.7/site-packages/mesonbuild/msetup.py", line 159, in generate
self._generate(env)
File "/usr/local/lib/python3.7/site-packages/mesonbuild/msetup.py", line 192, in _generate
intr.run()
File "/usr/local/lib/python3.7/site-packages/mesonbuild/interpreter.py", line 4359, in run
super().run()
File "/usr/local/lib/python3.7/site-packages/mesonbuild/interpreterbase.py", line 465, in run
self.evaluate_codeblock(self.ast, start=1)
File "/usr/local/lib/python3.7/site-packages/mesonbuild/interpreterbase.py", line 490, in evaluate_codeblock
raise e
File "/usr/local/lib/python3.7/site-packages/mesonbuild/interpreterbase.py", line 483, in evaluate_codeblock
self.evaluate_statement(cur)
File "/usr/local/lib/python3.7/site-packages/mesonbuild/interpreterbase.py", line 498, in evaluate_statement
self.assignment(cur)
File "/usr/local/lib/python3.7/site-packages/mesonbuild/interpreterbase.py", line 1151, in assignment
value = self.evaluate_statement(node.value)
File "/usr/local/lib/python3.7/site-packages/mesonbuild/interpreterbase.py", line 500, in evaluate_statement
return self.method_call(cur)
File "/usr/local/lib/python3.7/site-packages/mesonbuild/interpreterbase.py", line 895, in method_call
return obj.method_call(method_name, args, self.kwargs_string_keys(kwargs))
File "/usr/local/lib/python3.7/site-packages/mesonbuild/interpreterbase.py", line 39, in method_call
return method(args, kwargs)
File "/usr/local/lib/python3.7/site-packages/mesonbuild/interpreterbase.py", line 285, in wrapped
return f(*wrapped_args, **wrapped_kwargs)
File "/usr/local/lib/python3.7/site-packages/mesonbuild/interpreterbase.py", line 151, in wrapped
return f(*wrapped_args, **wrapped_kwargs)
File "/usr/local/lib/python3.7/site-packages/mesonbuild/interpreterbase.py", line 213, in wrapped
return f(*wrapped_args, **wrapped_kwargs)
File "/usr/local/lib/python3.7/site-packages/mesonbuild/interpreter.py", line 484, in partial_dependency_method
pdep = self.held_object.get_partial_dependency(**kwargs)
TypeError: get_partial_dependency() got an unexpected keyword argument 'source'
FAILED: build.ninja
```
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
The implementation of this function has changed enough that the name
doesn't really reflect what it actually does. It basically returns true
unless you're cross compiling, need and exe_wrapper, and don't have one.
The original function remains but is marked as deprecated.
This makes one small change the meson source language, which is that it
defines that can_run_host_binaries will return true in build == host
compilation, which was the behavior that already existed. Previously
this was undefined in build == host compilation.
The system tool is always the wrong thing to use and cause hard to debug
issues when trying to link system libraries with cross built binaries.
The ExternalDependency base class already had a method to deal with
this, used by PkgConfigDependency and QtBaseDependency, so it should
make things more consistent.
Discussions in #6524 have shown that there are various possible uses of the
kconfig module and even disagreements in the exact file format between
Python-based kconfiglib and the tools in Linux. Instead of trying to
reconcile them, just rename the module to something less suggestive and
leave any policy to meson.build files.
In the future it may be possible to add some kind of parsing through
keyword arguments such as bool_true, quoted_strings, etc. and possibly
creation of key-value lists too. For now, configuration_data objects
provide an easy way to access quoted strings. Note that Kconfig stores
false as "absent" so it was already necessary to write "x.has_key('abc')"
rather than the more compact "x['abc']". Therefore, having to use
configuration_data does not make things much more verbose.
Gtest can output junit results with a command line switch. We can parse
this to get more detailed results than the returncode, and put those in
our own Junit output. We basically just throw away the top level
'testsuites' object, then fixup the names of the tests, and shove that
into our junit.
* WIP: Document formal Meson grammar
* Various little fixes [skip ci]
1) Add missing logical_not_expr
2) 'in' and 'not in' are valid relational operators at least for dicts
3) dictionary keys can be expressions, but kwarg names cannot
4) typo logical_end_expression -> logical_and_expression
5) Make jump statements only allowed inside an iteration statement
* Rework EBNF style [skip ci]
As there is no good order for the productions, just go alphabetically.
The EBNF style was changed to match the one the Python lark project
uses, that is colons for productions and terminals enclosed in double
quotes.
* Add missing production for unary operators [skip ci]
* Add production for multiline strings [skip ci]
* Properly define terminal symbols [skip ci]
Depending on the EBNF flavor, regex can be used to describe the terminal
symbols. Lark allows this, and as it was mentioned as a possible user of
this grammar, let's follow its flavor here. Most regexes used are easily
human-readable, and we can always add comments to more complicated ones.
* Small changes to which expressions can be used where [skip ci]
Let the grammar be very general. The type system then has to check, that
the used expression really evaluates to the correct type. Even if we
know today that assignment expressions always evaluate to None (and can
therefore only be used as a toplevel expression in an expression
statement), this needn't be the case forever. So this way, the grammar
stays stable even if such changes were made.
* Rework function argument list production [skip ci]
* Be more verbose for production names [skip ci]
Rename expr -> expression, stmt -> statement, op -> operator, program ->
build_definition. Also adjust some list productions.
* Add paragraph about syntax stability promises [skip ci]
Update the test.json schema, adding the 'stdout' property.
Also amend the test.json schema so the presence of an unexpected
property on the root object causes a validation error.
v2:
Also add 'tools' property to json schema.
Amend the documentation not to use the word 'list' to describe a dict.
Expected stdout lines must match lines from the actual stdout, in the
same order. Lines with match type 're' are regex matched.
v2:
Ignore comment lines in expected_stdout
v3:
Automatically adjust path separators for location in expected output
v4:
Put expected stdout in test.json, rather than a separate file
Adds the `tools` section to `tests.json` to specify requirements
for the tools in the environment. All tests that fail at least
one tool requirements check are skipped.
- ExternalProgramHolder has path() method while CustomTargetHolder and
BuildTargetHolder have full_path().
- The returned ExternalProgramHolder's path() method was broken, because
build.Executable object has no get_path() method, it needs the
backend.
- find_program('overridden_prog', version : '>=1.0') was broken because
it needs to execute the exe that is not yet built. Now assume the
program has the (sub)project version.
- If the version check fails, interpreter uses
ExternalProgramHolder.get_name() for the error message but
build.Executable does not implement get_name() method.
JUnit is pretty ubiquitous, lots of services and results viewers
understand it, in particular gitlab and jenkins know how to consume
JUnit xml. This means projects using CI services can have their test
results consumed automatically.
Fixes: #6972
This does a couple of nice things, one is that editors like vscode can
be configured to use this schema to provide auto completion and error
highlighting if invalid values are added or required values are missing.
It also allows us test that the format of the test matrix work in a unit
test, which I've added. It does require that the python jsonschema
package is installed.
It can happen that a server is temporaly down, tarballs often have
many mirrors available so we should be able to add at least one fallback
mirror in wrap files.
Refine documentation of the default name_prefix, so people don't get the
impression they can write logic which uses 'lib' as the default, when
they should be defaulting to '[]', to let us take care of the
complexities.
Rather than having two separate sections with duplicated information
lets just have one for the common settings, and only document sections
specific to each file in separately
PR #6363 made it so our interpretation of env vars no longer clashed
with Autoconf's: if both Meson and Autoconf would read and env var, both
would do the same things with the value they read.
However, there were still cases that autoconf would read an env var when
meson wouldn't:
- Autoconf would use `CC` in cross builds too
- Autoconf would use `CC_FOR_BUILD` in native builds too.
There's no reason Meson can't also do this--if native cross files
overwrite rather than replace env vars, cross files can also overwrite
rather than replace env vars.
Because variables like `CC` are so ubiquitous, and because ignoring them
in cross builds just makes those builds liable to break (and things more
complicated in general), we bring Meson's behavior in line with
Autoconf's.
It may not be obvious to users that these two ways to set build-types
override each other and specifying both is redundant, and conflicts
are resolved based on whichever is specified later.
Closes https://github.com/mesonbuild/meson/issues/6742
This is needed when mixing D and C code, as it's possible to end up
witha combination of linkers and compilres such that C produces pdb
files but D does not.
This allows the harness to apply the version correctly, putting it in the right
place, dropping the right amount of numbers, etc.
pdb taking a version allows it to be more easily copied from the
shared_lib type.
[why]
Sometimes one want to set the 'Conflicts:' field in .pc files.
This is possible by using the 'conflicts' keyword argument in the
pkgconfig module. The feature is not documented on mesonbuild.org,
though.
But a warning is issued:
WARNING: Passed invalid keyword argument "conflicts".
WARNING: This will become a hard error in the future.
History:
It has been added along with kwarg 'url' with commit
309041918 pkgconfig: Add missing 'URL' and 'Conflicts' entries
Later the kwargs check has been introduced with
80d665e8d Converted some modules.
but both 'url' and 'conflicts' were missing.
With commit
2acf737b pkgconfig: Document url keyword
the 'url' kwarg has been added to the checks, but not 'conflicts'.
[how]
Add 'conflicts' to the allowed kwargs.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
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.
Otherwise you have to hunt through the source code. Specifically, this
is defined in `mesonbuild/coredata.py`: `set_buildtype_from_others()`
and `set_others_from_buildtype()`
As any child of BuildTargetHolder might need the name of the object,
provides a method to get object name.
This is useful in gst-build to display the plugin name and not
the filename.
Emscripten does have a stand alone linker, wasm-ld. This patch adds the
linker, adds detection for the linker, and removes the IsLinkerMixin for
emscripten. This is a little more correct, and makes the code a lot
cleaner and more robust.
Emscripten has pthread support (as well as C++ threads), but we don't
currently implement them. This fixes that by adding the necessary code.
The one thing I'm not sure about is setting the pool size. The docs
suggest that you really want to do this to ensure that your code works
correctly, but the number should really be configurable, not sure how to
set that.
Fixes#6684
This adds a warnings counter for subprojects that passed. This is to
encourage developpers to check warnings in the logs and hopefully fix
them. Otherwise they could be hidden in hundreds lines of logs.
This also print the error message for subprojects that did not pass. The
error message is often enough to fix the issue (e.g. missing
dependency) and it's easier than searching in the logs why a subproject
failed.
This is more correct, and forces the target(s) to be rebuilt if the
PDB files are missing. Increases the minimum required Ninja to 1.7,
which is available in Ubuntu 16.04 under backports.
We can't do the same for import libraries, because it is impossible
for us to know at configure time whether or not an import library will
be generated for a given DLL.
This makes two basic changes, 1 it moves the name of the linker into the
linker class, this should reduce the number of errors and typos, and
ensure that a linker always has one name. This then renames the linkers
to have more consistent names.
Posix/gnu linkers are called ld.<name>: ld.gold, ld.lld, ld.solaris.
Apple linkers are renamed ld64.
These are pretty much all over the place because I never intended them
to be exposed to the meson source language, they were meant just for
documentation.
This allows users to disable writing out the inbuilt variables to
the pkg-config file as they might actualy not be required.
One reason to have this is for architecture-independent pkg-config
files in projects which also have architecture-dependent outputs.
For example : https://gitlab.freedesktop.org/wayland/weston/issues/269Fixes#4011
This is a significant speed-up on Windows because terminals are
slow to print things out.
Speed-up in gst-build on Windows:
```
meson install:
before: 5.1 seconds
after: 4.0 seconds
```
This improves the common case of a simple meson.build which doesn't
contain any 'native: true' targets to not require a native compiler when
cross-compiling, without needing any changes in the meson.build.
v2:
Do it the right way around!
Currently it's just like if all builtin/base/compiler options are
yielding. This patch makes possible to have non-yielding builtin
options. The value in is overriden in this order:
- Value from parent project
- Value from subproject's default_options if set
- Value from subproject() default_options if set
- Value from command line if set
The documentation of "order-only" dependencies is limited and their
various purposes are especially not clear. See issue #6391 for a recent
example, search the internet for many more. So mention the particular
purpose here while making the documentation barely longer.
This allows Meson native-file [properties] to be used.
This avoids the need to call meson from a script file or have a
long command line invocation of `meson setup`
The method meson.get_native_property('prop', 'fallback') is added.
The native file can contain properties like
```
[properties]
myprop1 = 'foo'
mydir2 = 'lib/custom'
```
Then from within `meson.build`
```meson
x1 = meson.get_native_property('myprop1')
thedir = meson.get_native_property('mydir2', 'libs')
```
fallback values are optional
The rust code is ugly, because rust is annoying. It doesn't invoke a
linker directly (unless that linker is link.exe or lld-link.exe),
instead it invokes the C compiler (gcc or clang usually) to do it's
linking. Meson doesn't have good abstractions for this, though we
probably should because some of the D compilers do the same thing.
Either that or we should just call the c compiler directly, like vala
does.
This changes the public interface for meson, which we don't do unless we
absolutely have to. In this case I think we need to do it. A fair number
of projects have already been using 'ld' in their cross/native files to
get the ld binary and call it directly in custom_targets or generators,
and we broke that. While we could hit this problem again names like
`c_ld` and `cpp_ld` are far less likely to cause collisions than `ld`.
Additionally this gives a way to set the linker on a per-compiler basis,
which is probably in itself very useful.
Fixes#6442
This fixes an issue with generated sources and object libraries, as
well as an issue on windows with the `link` linker and the vs backend.
The last issue is resolved by building the source files multiple times
to avoid extracting object files in meson.
this can be useful for if/elif where linker behaviors must be
considered.
For example, clang with "link" vs gcc with "ld.bfd" etc.
ci for compiler.get_linker_id() method
doc
add @FeatureNew check
Co-Authored-By: Daniel Mensinger <daniel@mensinger-ka.de>
is_samepath better reflects the nature of this function--that files
and directories can be compared.
Also, instead of raising exceptions, simply return False when one
or both .is_samepath(path1, path1) don't exist. This is more
intuitive behavior and avoids having an extra if fs.exist() to go
with every fs.is_samepath()
Meson's documentation about cross-compilation made me finally understand
why the typical confusion about machine names. Thanks, but let's make it
even better. Don't wait until the very end of the section to reveal the
most important information: that machine names are relative. For
suspense we already have TV shows; spill the beans much earlier.
Also fix the first, simplest cross-compilation example: target is
irrelevant.
This default behavior can have surprising and time-consuming outcomes.
I was wondering why certain tests using several external, fixed libraries
would fail only with Meson and not with CMake or manual runs.
It turned out mtest.py enables MALLOC_PERTURB_ by default, which is
surprising--a topic for another Issue/PR.
At least, this surprising default is documented with workarounds.
Xavier Claessens