Fix module build

[MeanSquaredError]

This PR fixes a bug which prevented building any of the test code with modules enabled. The bug manifested on my machine with the following setup

g++ (GCC) 16.1.1 20260515 (Red Hat 16.1.1-2)
cmake version 4.3.0

and the following build commands:

cmake -B build -G Ninja -DBUILD_TESTING=ON -DDEPENDENCY_CHECK=ON -DBUILD_WITH_MODULES=ON
cmake --build build

caused the following build error:

root@fedora:/usr/local/projects/github/sqlpp23# cmake -B build -G Ninja -DBUILD_TESTING=ON -DDEPENDENCY_CHECK=ON -DBUILD_WITH_MODULES=ON
-- The CXX compiler identification is GNU 16.1.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Python3: /usr/bin/python3.14 (found version "3.14.6") found components: Interpreter
-- Pyparsing is installed: Enabling sqlpp23-ddl2cpp tests.
-- Configuring done (0.7s)
-- Generating done (0.3s)
-- Build files have been written to: /usr/local/projects/github/sqlpp23/build
root@fedora:/usr/local/projects/github/sqlpp23# cmake --build build
[522/680] Linking CXX executable tests/core/asserts/sqlpp23_core_asserts_setup_bad_returning_as
FAILED: [code=1] tests/core/asserts/sqlpp23_core_asserts_setup_bad_returning_as 
: && /usr/bin/c++  -Wl,--dependency-file=tests/core/asserts/CMakeFiles/sqlpp23_core_asserts_setup_bad_returning_as.dir/link.d tests/core/asserts/CMakeFiles/sqlpp23_core_asserts_setup_bad_returning_as.dir/bad_returning_as.cpp.o -o tests/core/asserts/sqlpp23_core_asserts_setup_bad_returning_as  tests/core/libsqlpp23.test.core.tables.module.a && :
/usr/bin/ld.bfd: tests/core/asserts/CMakeFiles/sqlpp23_core_asserts_setup_bad_returning_as.dir/bad_returning_as.cpp.o: in function `__static_initialization_and_destruction_0()':
bad_returning_as.cpp:(.text+0x38): undefined reference to `initializer for module sqlpp23.mock_db'
collect2: error: ld returned 1 exit status
[527/680] Building CXX object tests/core/usage/statement/CMakeFiles/sqlpp23_core_usage_statement_select.dir/select.cpp.o
ninja: build stopped: subcommand failed.
root@fedora:/usr/local/projects/github/sqlpp23# 

After some investigation it turned out that the culprit is the use of INTERFACE targets for the various tests (e.g. sqlpp23_core_testing). The interface targets don't propagate the compiled .o files owned by the OBJECT targets they depend on. Instead the INTERFACE targets silently drop the .o files without using them. As a result the initialization code for module sqlpp23.mock_db, which is inside the .o files, is silently dropped and the linker complains when it tries to use it.

I don't know why the code worked fine until now and I only saw this bug now. I am pretty sure that building sqlpp23 with modules and testing worked fine for me until now, when it just stopped working :-)

I suspect I think that this bug existed before, but we just haven't come across it now.

My prime suspect is the new GCC 16.1.1. I think that the previous versions of GCC were optimizing happily the static constexpr vars in

sqlpp23/include/sqlpp23/core/debug_logger.h

Line 40 in e4f47a8

static constexpr inline bool debug_enabled = true;

and

sqlpp23/include/sqlpp23/core/database/transaction.h

Line 33 in e4f47a8

static constexpr bool quiet_auto_rollback = false;

but the new GCC actually emits those constants into the .text section of the object files and actually generates some static initializer code that should be called on startup, so the module sqlpp23.mock_db now needs to be initialized at runtime. Previously dropping the .o files was OK, because there was no initialization function in them, so no linker errors were caused.

But all that is just an educated guess, because I don't have the old GCC and CMake, so I cannot check what code they were generating in the past.

Anyway, this PR fixes the problem by changing the test library target from OBJECT to the default static/dynamic type. The PR also cleans up a bit the CMake code that generates the test targets. I think there are more cleanups of the CMake test code that could (and probably should) be done, but I guess this can wait until I get the time and inspiration (or until someone else does :-)

EDIT: I built and tested this PR with both

cmake -B build -G Ninja -DBUILD_POSTGRESQL_CONNECTOR=ON -DBUILD_SQLITE3_CONNECTOR=ON -DBUILD_MYSQL_CONNECTOR=ON -DBUILD_TESTING=ON -DDEPENDENCY_CHECK=ON -DBUILD_WITH_MODULES=ON

and

cmake -B build -G Ninja -DBUILD_POSTGRESQL_CONNECTOR=ON -DBUILD_SQLITE3_CONNECTOR=ON -DBUILD_MYSQL_CONNECTOR=ON -DBUILD_TESTING=ON -DDEPENDENCY_CHECK=ON

[MeanSquaredError]

There seem to be some failing checks so I am turning this into a draft until I find out what is going on.

[MeanSquaredError]

OK, I found the problem with MSVC. I don't want to fix it with a quick hack, so I'll provide a proper fix later today. Until then I am leaving the PR as a draft.

[MeanSquaredError]

OK, it should be ready for a review now.

[rbock]

Successfully tested with gcc-15.2.0 and cmake-3.31.6

I left a couple of comments and questions.

[MeanSquaredError]

Successfully tested with gcc-15.2.0 and cmake-3.31.6

Do you mean that you tested the old code (before this PR) with gcc-15.2.0 and cmake-3.31.6 and it compiled successfully with modules?

Or do you mean that you tested the new code (with this PR) with gcc-15.2.0 and cmake-3.31.6 and it compiled successfully with modules?

[rbock]

Or do you mean that you tested the new code (with this PR) with gcc-15.2.0 and cmake-3.31.6 and it compiled successfully with modules?

This :-)

[MeanSquaredError]

Or do you mean that you tested the new code (with this PR) with gcc-15.2.0 and cmake-3.31.6 and it compiled successfully with modules?

This :-)

OK, thanks for the clarification. I am somewhat convinced that the reason for the problem is that gcc started emitting those static constexpr global vars into the .text section, instead of treating them as constants and optimizing them away. I guess they probably changed something in their default optimization settings.

[rbock]

This looks good to me at this point. Happy to merge if you agree.

[MeanSquaredError]

This looks good to me at this point. Happy to merge if you agree.

I do agree. Let's merge the current PR and its code is an improvement over the current state (it fixes one build bug and removes some code duplication). Then we can improve the code further in other PR(s).

[rbock]

Thanks for the fix, cleanup, and discussion!