Add option to build shared library

[bkmgit]

No description provided.

[stephenberry]

What is your intention of building ut as a shared library? This library uses source location for helpful output, which would be lost as a shared library. And, it is extremely little code with minimal compilation overhead.

[bkmgit]

Helpful to test Glaze when packaging:

• https://bugzilla.redhat.com/show_bug.cgi?id=2445809

At present ctest does not run any tests:
https://github.com/stephenberry/glaze/blob/main/util/glaze.spec#L81

[stephenberry]

@bkmgit, would it be helpful for Glaze to have its own copy of this ut code so that this dependency isn't needed in Glaze?

Was your idea to link Glaze unit tests to the ut shared library? Because right now Glaze unit tests would require the header file anyway. I'm trying to understand what the shared library would give you, it just seems to add complications and worse security.

[bkmgit]

It is possible to package ut as a header only library, but assumed it is good to have all options available.

[bkmgit]

Bundling ut with Glaze is not desirable.

[stephenberry]

It is possible to package ut as a header only library, but assumed it is good to have all options available.

The library just doesn't work as a shared library, it relies on templates and source location. So, no one would want to use a shared library version of this code.

[bkmgit]

Modules support gets compiled as a static library. Can it be used as a shared library?

[stephenberry]

C++20 modules don't get compiled to a static libraries (although they do produce object files). ut would not work well as a traditional static library. Modules produce Binary Module Interface (BMI) files for inline and template code (understanding the AST) and object files for compiled code, but not static libraries.

Static libraries don't work for templates and inline constexpr evaluated code, but C++20 modules do work in these cases.

[DockedFerret800]

+1 for @stephenberry position here. I don't quite understand the need for shared library in UT's case.

[bkmgit]

It seems some kind of versioning is suggested:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1767r0.html#linkage

but still reading up on how to package the module.

[bkmgit]

It seems the extension should be cppm:

https://crascit.com/2024/04/04/cxx-modules-cmake-shared-libraries/

but what CMake should do is still be worked out:
https://gitlab.kitware.com/cmake/cmake/-/work_items/25539

[DockedFerret800]

File extension doesn't impact this, so I don't think that's the case.

[stephenberry]

@bkmgit, this is obviously AI generated, but I think helpful to explain the ut library and how to fix the fedora issue:

---

Packaging ut for Fedora

This addresses the Fedora packaging discussion related to Bug 2445809 (Glaze package review) and PR #8 (shared library proposal).

Summary

ut is a header-only C++ unit testing library consisting of a single header file (include/ut/ut.hpp). It should be packaged for Fedora as a header-only / devel-only package. A shared library build is not appropriate for this library and will not produce a functional result.

Why a shared library does not work

ut relies heavily on:

• C++ templates -- The core test runner, assertions, and reporting are all templated. Templates must be instantiated at the call site (i.e., in the consuming translation unit), not in a pre-compiled shared library.
• std::source_location -- Test failure reporting uses source_location default arguments to capture the file name and line number of the caller. If the code were compiled into a shared library, source_location would resolve to the library's own source file and line numbers, making test output useless.
• constexpr and inline functions -- Much of the library is constexpr/consteval and is evaluated at compile time in the consumer's context.

These are fundamental design characteristics, not implementation details that can be worked around.

Correct packaging approach

ut already provides standard CMake install targets that work correctly for distro packaging:

cmake -B build -DCMAKE_INSTALL_PREFIX=/usr
cmake --install build

This installs:

• Header file: include/ut/ut.hpp
• CMake config files: utConfig.cmake, utConfigVersion.cmake, utTargets.cmake (to share/ut/)

Downstream consumers use it via:

find_package(ut REQUIRED)
target_link_libraries(my_target PRIVATE ut::ut)

Suggested Fedora spec structure

The package should be an architecture-independent (noarch) devel package since it contains only headers and CMake configuration files. A suggested spec outline:

Name:           ut
Version:        1.2.0
Release:        1%{?dist}
Summary:        A simple, single-header C++ unit testing framework

License:        MIT
URL:            https://github.com/openalgz/ut
Source0:        %{url}/archive/v%{version}/%{name}-%{version}.tar.gz

BuildArch:      noarch

BuildRequires:  cmake >= 3.31
BuildRequires:  gcc-c++

%description
ut is a simple, header-only C++ unit testing framework that provides
lightweight test registration, assertions with source location reporting,
and colored output.

%package        devel
Summary:        Development files for %{name}
Provides:       %{name}-static = %{version}-%{release}

%description    devel
Header files and CMake configuration for the ut unit testing framework.

%prep
%autosetup -n %{name}-%{version}

%build
%cmake
%cmake_build

%install
%cmake_install

%check
%ctest

%files devel
%license LICENSE
%doc README.md
%{_includedir}/ut/
%{_datadir}/ut/

Running tests

ut has a test suite enabled when built as the top-level project with BUILD_TESTING=ON (the CMake/CTest default). The tests cover the UT_RUN filtering feature and basic library functionality. Running ctest during %check will exercise these tests.

C++20 modules

The UT_ENABLE_MODULES option provides experimental C++20 module support. This uses a STATIC library target as required by CMake's module infrastructure to produce Binary Module Interface (BMI) files -- this is a CMake implementation detail, not an indication that ut should be distributed as a compiled library. C++20 module packaging for distros is still an evolving area (see CMake issue #25539) and is not needed for Glaze's use of ut, which consumes it as a traditional header-only library.

[bkmgit]

I have a spec file:
https://fed500.fedorapeople.org/ut.spec

main unresolved issue is how to package the module.

[stephenberry]

@bkmgit, currently the module isn't used by Glaze and I don't think there are standard practices for packaging modules right now. Typically modules would be built in place and not packaged like libraries.

[bkmgit]

Both Poco and nlohmann-json create modules. These can either be shared or static libraries. When created as shared libraries, sonames are included. Poco in addition installs cppm files. A list of other C++ libraries with module is available at https://arewemodulesyet.org/projects/

[stephenberry]

nlohmann-json's module target produces a static library as a CMake artifact for the BMI. ut used this same pattern already with UT_ENABLE_MODULES.

if(UT_ENABLE_MODULES)                                                         
    add_library(${PROJECT_NAME}_${PROJECT_NAME} STATIC)

This is not a traditional static library, but it is CMake's approach to the BMI and you can use it in the same way that nlohmann-json's module handling works.

---

As for shared libraries, it doesn't work with ut and poco is a different kind of codebase with .cpp files an non-templated interfaces.