| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
Qt offers a tool to automatize most of what needs to be done regarding its libraries.
|
|
python compiled extensions should never need to expose any symbol other
than PyInit_* which is declared with default visibility via
PyMODINIT_FUNC on supported compilers.
Thus, a reasonably sane default is to mark any other symbols as hidden,
while still respecting any manually specified visibility.
Gate this on the version of python itself, as not all versions decorate
PyMODINIT_FUNC properly.
|
|
Otherwise it always returns the value for c++98, starting with MSVC 2017
15.7 or later. Earlier versions are not affected by this mis-feature.
See: https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-160
This was originally applied as 0b97d585480e973d8b149618901f7a4ddfa1a906
but later reverted because it made the CI red. Try it again, now.
Original-patch-by: Dylan Baker <dylan@pnwbakers.com>
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
|
|
|
|
gcovr will read this file anyway, but if it exists we don't need to
assume that the project wishes to exclude subprojects/ -- they can
determine that themselves.
Fixes #3287
Closes #9761
lcov doesn't read the config file by default, but we can do the smart
thing here.
Fixes #4628
|
|
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.
|
|
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
|
|
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
|
|
+ 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
|
|
|
|
This makes vcs_tag behave like other commands so it accepts not only
string and file arguments, but also exe, custom_tgt, and
external_program.
|
|
|
|
- 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
|
|
Manually running hotdoc's upload command does not guarantee the docs
have actually been built.
|
|
Fixed broken link and updated outdated description.
|
|
|
|
|
|
|
|
|
|
|
|
It isn't possible to have one target depend on a run_target, because
those produce no outputs and are always out of date. But the docs didn't
specify which types of target are valid here.
Correct the docs to align with the implementation.
Fixes #10198
|
|
This was implemented in commit 280346da3ac5904ec097afe89ef45ad34bd4a173
but never properly documented (it predated the version-controlled docs).
|
|
We have always accepted an int here as an alternative to a string, but
the initial documentation thought it was only a string.
|
|
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
|
|
|
|
In the original RefMan 2.0 implementation, this incorrectly started
claiming that the default is false.
Fixes #10155
|
|
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
|
