| commit | 509a140529328f316702411b8e9940a930340d52 | [log] [tgz] |
|---|---|---|
| author | Sam James <sam@gentoo.org> | Tue Mar 12 22:37:44 2024 +0000 |
| committer | Eli Schwartz <eschwartz93@gmail.com> | Thu Mar 28 00:52:25 2024 -0400 |
| tree | 624bfbc2793f4d7453b9a4abf069bb3c4394a127 | |
| parent | 80e1d28b042def24b7325f84247dadf94c507bfd [diff] |
compilers: cpp: relax assertion level for libc++ Followup to 90098473d51e6f059e775f1833b0a2ea91c8f8f9. I changed my mind on this a few times. libcxx's documentation describes [0] the hardening modes as: """ 1) Unchecked mode/none, which disables all hardening checks. 2) Fast mode, which contains a set of security-critical checks that can be done with relatively little overhead in constant time and are intended to be used in production. We recommend most projects adopt this. 3) Extensive mode, which contains all the checks from fast mode and some additional checks for undefined behavior that incur relatively little overhead but aren’t security-critical. Production builds requiring a broader set of checks than fast mode should consider enabling extensive mode. The additional rigour impacts performance more than fast mode: we recommend benchmarking to determine if that is acceptable for your program. 4) Debug mode, which enables all the available checks in the library, including internal assertions, some of which might be very expensive. This mode is intended to be used for testing, not in production. """ We chose 3) before because it felt like a better fit for what we're trying to do and the most equivalent option to libstdc++'s _GLIBCXX_ASSERTIONS, but on reflection, maybe we're better off picking a default with less overhead and more importantly guarantees constant time checks. [0] https://libcxx.llvm.org/Hardening.html#using-hardening-modes Bug: https://github.com/mesonbuild/meson/issues/12962 Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Latest Meson version supporting previous Python versions:
Meson is available on PyPi, so it can be installed with pip3 install meson. The exact command to type to install with pip can vary between systems, be sure to use the Python 3 version of pip.
If you wish you can install it locally with the standard Python command:
python3 -m pip install meson
For builds using Ninja, Ninja can be downloaded directly from Ninja GitHub release page or via PyPi
python3 -m pip install ninja
More on Installing Meson build can be found at the getting meson page.
Meson can be run as a Python zip app. To generate the executable run the following command:
./packaging/create_zipapp.py --outfile meson.pyz --interpreter '/usr/bin/env python3' <source checkout>
Meson requires that you have a source directory and a build directory and that these two are different. In your source root must exist a file called meson.build. To generate the build system run this command:
meson setup <source directory> <build directory>
Depending on how you obtained Meson the command might also be called meson.py instead of plain meson. In the rest of this document we are going to use the latter form.
You can omit either of the two directories, and Meson will substitute the current directory and autodetect what you mean. This allows you to do things like this:
cd <source root> meson setup builddir
To compile, cd into your build directory and type ninja. To run unit tests, type ninja test.
More on running Meson build system commands can be found at the running meson page or by typing meson --help.
We love code contributions. See the contribution page on the website for details.
The channel to use is #mesonbuild either via Matrix (web interface) or OFTC IRC.
More information about the Meson build system can be found at the project's home page.
Meson is a registered trademark of Jussi Pakkanen.