| Age | Commit message (Collapse) | Author |
|
Fixes #10901
|
|
|
|
The new support was added to fs.name, fs.parent, fs.replace_suffix, and
fs.stem.
|
|
This way the `rust.bindgen` can generate a second output being a C file,
which contains wrapper functions for static inline ones.
This output file can then be compiled via C targets.
|
|
Fixes #6567
|
|
Followup to 7b7d2e060b447de9c2642848847370a58711ac1c which handles ASAN and UBSAN.
It turns out that MSAN needs the same treatment. I've checked other sanitizers
like HWASAN and TSAN - it looks like they may both need it too, but Meson doesn't
currently suppose those anyway (see https://github.com/mesonbuild/meson/pull/12648).
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
|
|
This allows us to ensure that the bindgen we're using is suitable for
our purpose.
|
|
Especially for C++ this is very important.
|
|
This may be of particular use when a header is .h but should be treated
as a C++ header instead of a C header.
|
|
Bindgen natively only considers .hpp to be C++ headers, but Meson
considers some additional extensions including .hh and .hxx to be C++.
|
|
This was inherited from documentation of build target, but some sentences do not make sense in the context of the preprocessor.
|
|
They accept list as documented
|
|
A config-tool method has been supported since c02593f and it says so
just a few lines below the outdated statement.
|
|
This allow to generate ui and moc under subdirectories,
as this is allowed with generic generators.
|
|
|
|
This was implemented in dc51740e2cdee171ac6ebc7ed261e5c08730c9a9,
but was not added to the documentation or marked as a new feature.
|
|
These are being added for NumPy 2.0 The implementation closely follows
the one for the pybind11 dependency.
|
|
Use common conventions for documentation of shared library version and
soversion. In general, the numeric version part is expected to be first
component of version, so suggest this in the example code.
|
|
`meson <options> -Dxxx=yyy` is technically accurate, but does cause
confusion at least some of the time.
|
|
|
|
In commit 83a973ca04cf53dd98ff487b4273155b82cf554a a bunch of strange
changes were made, that were not even tested. Make sure people get the
correct command for running coverage targets.
|
|
This patch adds 'depends' keyword to compiler.preprocess().
It allows to execute other targets before doing the preprocessing.
Test-case is added to demonstrate that functionality: it
generates the header before preprocessing the C source that
uses that generated header.
Thanks to @bruchar1 for getting this patch to work.
|
|
Closes: https://github.com/mesonbuild/meson/issues/12702
|
|
When compiling on Windows using MSVC, you also need to link the SDL2main.lib file.
I've added a note to the GuiTutorial.md file to mention this.
|
|
For Clang, we now pass -D_GLIBCXX_DEBUG=1 if debugstl is enabled, and
we also pass -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_DEBUG.
Per https://discourse.llvm.org/t/building-a-program-with-d-libcpp-debug-1-against-a-libc-that-is-not-itself-built-with-that-define/59176/3,
we can't use _LIBCPP_DEBUG for older Clang versions as it's unreliable unless
libc++ was built with it.
We choose MODE_DEBUG for stldebug while building with assertions will do
MODE_EXTENSIVE.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
None of the options set here affect ABI and are intended for detecting constraint
violations.
For GCC, we simply need to set -D_GLIBCXX_ASSERTIONS.
For Clang, the situation is far more complicated:
* LLVM 18 uses a 'hardened mode' (https://libcxx.llvm.org/Hardening.html).
There are several levels of severity available here. I've chosen
_LIBCPP_HARDENING_MODE_EXTENSIVE as the strongest-but-one. The strongest
one (_DEBUG) doesn't affect ABI still but is reserved for stldebug.
* LLVM 15 uses a similar approach to libstdc++ called '_LIBCPP_ENABLE_ASSERTIONS'
Note that LLVM 17 while in development had fully deprecated _LIBCPP_ENABLE_ASSERTIONS
in favour of hardened, but changed its mind last-minute: https://discourse.llvm.org/t/rfc-hardening-in-libc/73925/4.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
Add support for specifying Cython compiler using the CYTHON environment
variable. If not set, proceed with the names hard coded for Cython.
|
|
Especially relevant for users of Ubuntu 22.04 which has packages for
Qt 6.2 and Meson 0.61.
a606ce22e ("Add support for Qt 6.1+", 2022-01-08)
d68a0651e ("qt module: also prefer the changed name scheme for the tools", 2022-02-09)
|
|
|
|
|
|
|
|
In commit 58c2aeb5e433ae7652488d53021c40db1712dea5, an asterisk used to
indicate "see note at bottom" was doubled up into an "italicize this
paragraph", which didn't contextually make any sense.
See: https://github.com/mesonbuild/meson/pull/12674#issue-2057666653
|
|
CLion was not mentioned in the list of IDE integrations. This commit adds it, also
adds a “3rd party" prefix to the Meson Syntax Highlighter plugin to indicate that it doesn't come from JetBrains, and sorts the list alphabetically.
|
|
* Update Users.md
|
|
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
|
|
|
|
This properly sets the project version in projects meson generates from
cmake projects. This allows dependency fallbacks to properly check the
version constraints in dependency calls when falling back to a cmake
subproject. Before this would fail, because the project version was
undefined.
|
|
If an annotation could not be resolved, it's classified as a "missing
import" and our configuration ignored it:
```
Skipping analyzing "mesonbuild.backends": module is installed, but missing library stubs or py.typed marker
```
As far as mypy is concerned, this library may or may not exist, but it
doesn't have any typing information at all (may need to be installed
first).
We ignored this because of our docs/ and tools/ thirdparty dependencies,
but we really should not. It is trivial to install them, and then
enforce that this "just works".
By enforcing it, we also make sure typos get caught.
|
|
This is needed now that str.format() is not allowing it any more. It is
also more consistent with other objects that have that method as well,
such as build targets.
Fixes: #12406
|
|
Change the shell prompt to '#' to when installing as root.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
|
|
|
|
Signed-off-by: Filipe Laíns <lains@riseup.net>
|
|
Releases have been happening an average of once every 90 days for the
past two years (since 0.60.0). If we just look at releases since 1.0.0,
the average is over 100 days.
|
|
> error: unsupported option '--target'; did you mean '-target'?
|
|
|
|
|
|
It was previously impossible to do this:
```
dep.get_pkgconfig_variable(
'foo',
define_variable: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
since get_pkgconfig_variable mandated exactly two (if any) arguments.
However, you could do this:
```
dep.get_variable(
'foo',
pkgconfig_define: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
It would silently do the wrong thing, by defining "prefix" as
`/usr=datadir=/usr/share`, which might not "matter" if only datadir was
used in the "foo" variable as the unmodified value might be adequate.
The actual intention of anyone writing such a meson.build is that they
aren't sure whether the .pc file uses ${prefix} or ${datadir} (or which
one gets used, might have changed between versions of that .pc file,
even).
A recent refactor made this into a hard error, which broke some projects
that were doing this and inadvertently depending on some .pc file that
only used the second variable. (This was "fine" since the result was
essentially meaningful, and even resulted in behavior identical to the
intended behavior if both projects were installed into the same prefix
-- in which case there's nothing to remap.)
Re-allow this. There are two ways we could re-allow this:
- ignore it with a warning
- add a new feature to allow actually doing this
Since the use case which triggered this bug actually has a pretty good
reason to want to do this, it makes sense to add the new feature.
Fixes https://bugs.gentoo.org/916576
Fixes https://github.com/containers/bubblewrap/issues/609
|
|
|
|
|