Greetings! 馃憢
There appears to be an inconsistency in how the Boost.Exception library is built and packaged depending on the build system used (b2 vs. CMake). I know b2 is the official one and CMake is optional, but this difference and as b2 only provide static library makes me think about this case.
With b2: The library forces a static build. Even when passing the global link=shared property to b2 to generate shared libraries across Boost, Boost.Exception overrides this behavior in its build configuration, hardcoding it to build strictly as a static library.
With CMake: The CMakeLists.txt configures Boost.Exception entirely as a header-only (INTERFACE) library, offering no option to build a compiled/pre-built library component.
-
Is the static restriction in Jamfile.v2 intended design, or is it a legacy artifact/bug?
-
Is Boost.Exception officially supposed to be treated strictly as a header-only library going forward (as suggested by the CMake configuration)?
Regards!
Greetings! 馃憢
There appears to be an inconsistency in how the Boost.Exception library is built and packaged depending on the build system used (b2 vs. CMake). I know b2 is the official one and CMake is optional, but this difference and as b2 only provide static library makes me think about this case.
With b2: The library forces a static build. Even when passing the global link=shared property to b2 to generate shared libraries across Boost, Boost.Exception overrides this behavior in its build configuration, hardcoding it to build strictly as a static library.
With CMake: The CMakeLists.txt configures Boost.Exception entirely as a header-only (INTERFACE) library, offering no option to build a compiled/pre-built library component.
Is the static restriction in Jamfile.v2 intended design, or is it a legacy artifact/bug?
Is Boost.Exception officially supposed to be treated strictly as a header-only library going forward (as suggested by the CMake configuration)?
Regards!