2
0
mirror of https://github.com/boostorg/pfr.git synced 2026-01-19 04:22:13 +00:00

7 Commits

Author SHA1 Message Date
Antony Polukhin
228922fdb5 Update copyright years 2026-01-04 11:26:11 +03:00
Alexander Grund
7aa41ed4f5 CMake: Condition core_name tests on CMake version (#224)
As those tests require C++20 only compile them with CMake 3.12+ to be able to use `cxx_std_20`
2025-10-28 19:40:55 +03:00
Alexander Grund
7509049f2c Fix compatibility with CMake < 3.14 (#223)
`NAME_WLE` was introduced in 3.14
2025-10-06 19:38:26 +03:00
Antony Polukhin
8cbffcb7ab Harden the CI checks for CMake and fix some issues (#215)
Fixes: https://github.com/boostorg/pfr/issues/214
2025-06-27 20:23:23 +03:00
Antony Polukhin
9bc3cb2af7 Another fix attempt for the CMake build from the root directory of Boost (#209)
Fixes https://github.com/boostorg/pfr/issues/206
2025-06-17 09:51:17 +03:00
Antony Polukhin
57fa1018b0 Update OSes in CI and run CMake tests (#207)
Fixes https://github.com/boostorg/pfr/issues/205
2025-06-11 21:40:44 +03:00
Antony Polukhin
5a48d7456f Rewrite modules following the new recommended Boost practice (#196)
Changes:

1) `#include <boost/pfr...` is now implicitly does `import boost.pfr` if the modules are supported 
2) CI now tests modules on Ubuntu 24.04 with existing runtime tests
3) Renamed module to `boost.pfr`
4) CMakeLists.txt now uses modules for `Boost::pfr` target if modules are supported
5) All the library internals now have unconditional module level linkage. `1)` allows users to mix `#include <boost/pfr...` and `import boost.pfr` in user code without ODR-violations.

Significant differences from https://anarthal.github.io/cppblog/modules3:
* PFR uses a `BOOST_PFR_USE_STD_MODULE` macro for `import std;` / `includes` while building module. This allows to use `boost.pfr` module in C++20 and even without usable  `std` module.
2025-04-16 09:16:09 +03:00