| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
|
|
The doc about declare_dependency states
d_module_features instead of d_module_versions
|
|
+ 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.
|
|
* update sample image
* increase size so all text will be shown
|
|
dependencies: allow get_variable to expose files from subprojects
|
|
|
|
[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>
|
|
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.
|
|
|
|
"Debug" is not a very helpful help message.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Meson already supplies the same value
|
|
|
|
- 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.
|
|
Companion to https://github.com/mesonbuild/meson/pull/10284
|
|
Fixed broken link and updated outdated description.
|
|
|
|
|
|
|
|
Adds a new debug() function that can be used in the meson.build to
log messages to the meson-log.txt that will not be printed to stdout
when configuring the project.
|
|
|
|
Added in commit 6240920c213fb76b4e4be8b6b59ae3346cbbcf77 and documented
in release notes but not in module docs.
|
|
Previously subprojects inherited languages already added by main
project, or any previous subproject. This change to have a list of
compilers per interpreters, which means that if a subproject does not
add 'c' language it won't be able to compile .c files any more, even if
main project added the 'c' language.
This delays processing list of compilers until the interpreter adds the
BuildTarget into its list of targets. That way the interpreter can add
missing languages instead of duplicating that logic into BuildTarget for
the cython case.
|
|
VSCode is perfectly happy with the trailing `---`, hotdoc only likes
`...` apparently.
|
|
|
|
Previously Meson lacked the ability to add resources to jar files.
Fixes #9945
|
|
|
|
This reverts commit 79c6075b560dbf1c3e4e0b30f1c472dc2086421e.
# Conflicts:
# docs/markdown/snippets/devenv.md
# mesonbuild/modules/python.py
# test cases/unit/91 devenv/test-devenv.py
PYTHONPATH cannot be reliably determined. The standard use case for
installing python modules with Meson is mixed pure sources (at least
`__init__.py`) and compiled extension_modules or configured files.
Unfortunately that doesn't actually work because python will not load
the same package hierarchy from two different directories, one a source
directory and one a (mandatory) out of tree build directory.
(It kind of can, but you need to do what this test case accidentally
stumbled upon, which is namespace packages. Namespace packages are a
very specific use case and you are NOT SUPPOSED to use them outside that
use case, so people are not going to use them just to circumvent Meson
devenv stuff as that would have negative install-time effects.)
Adding PYTHONPATH anyway will just lead to documentation commitments
which we cannot actually uphold, and confusing issues at time of use
because some imports *will* work... and some will *not*. The end result
will be a half-created tree of modules which just doesn't work together
at all, but because it partially works, users attempting to debug it
will spend time wondering why parts of it do import.
For any case where the automatic devenv would work correctly, it will
also work correctly to use `meson.add_devenv()` a single time, which is
very easy to manually get correct and doesn't provide any significant
value to automate.
In the long run, an uninstalled python package environment will require
"editable installs" support.
|
|
Structured Sources
|
|
|
|
dataonly files are architecture independent (lib vs lib64 for example).
Fixes #9902
|
|
|
|
This reverts commit e257a870fe5e676c55a2282b0e7fc9be34bba2ac.
The PR adding this command had infinitely hanging CI, and now that it is
merged to master we cannot get any CI on any PR to succeed.
|
|
|
|
|
|
|
|
This is hardly complete, but it's a start.
|
|
|
|
It is often useful to check the found version of a program without
checking whether you can successfully find
`find_program('foo', required: false, version: '>=XXX')`
|
|
Disabling targets because the tools used to build them aren't available
is a pretty suspicious thing to do. Users who want this are probably, in
general, advised to check themselves whether it is possible to build
those targets with find_program(..., required: false)
The i18n.gettext() invocation is a bit unusual because the product of
running it is non-critical files, specifically, translation catalogs. If
users don't have the tools needed to build them, they may not be able to
use them either, because perhaps they have NLS disabled on their
platform or it's difficult to put it in the bootstrap path.
So, for this reason, it was made non-fatal and the message catalogs are
just not created, and the resulting build is still perfectly usable
*unless* you want to use it in another language, at which point it
"works" but the text is all inscrutable to the end user, and that's a
feature of the target platform.
That's an acceptable tradeoff for translation catalogs.
It is NOT an acceptable tradeoff for merge_file, which produces desktop
files or MIME database catalogs or other files which have crucial roles
to perform, without which the software in question simply doesn't work
at all. In such cases, this just fails to install crucial files, users
report bugs to the project in question, and the project adds
`find_program('xgettext')` to guarantee the hard error due to lack of
confidence in Meson.
Fixes #6165
Fixes #8436
|
|
- Change `scope` kwarg to `public` boolean default to false.
- Change `side` kwarg to `client` and `server` booleans.
- Document returned values
- Aggregate in a single unit test because have lots of small tests
increases CI time.
Fixes: #10040.
|
|
|
|
This allows someone to link against libjvm.so and libjawt.so.
|
|
|
|
|
|
JNI is a more apt name because it currently only supports the JNI. I
also believe that CMake uses the terminology JNI here as well.
JNI is currently the only way to interact with the JVM through native
code, but there is a project called "Project Panama" which aims to be
another way for native code to interact with the JVM.
|
|
java.generate_native_headers()
After implementing a much more extensive Java native module than what
currently exists in the tests, I found shortcomings.
1. You need to be able to pass multiple Java files.
2. Meson needs more information to better track the generated native
headers.
3. Meson wasn't tracking the header files generated from inner classes.
This new function should fix all the issues the old function had with
room to grow should more functionality need to be added. What I
implemented here in this new function is essentially what I have done in
the Heterogeneous-Memory Storage Engine's Java bindings.
|
|
|
|
It prints all envorinmente variables that have been modified. Can be
used by shell scripts that wish to setup their environment themself.
|
|
When the project instals GDB helper scripts, copy them into
meson-private directory with the right tree layout and write a .gdbinit
script to load them automatically.
|
