Ah, the failing CI stuff for SQLite3 seems like an IWYU error. I'll ensure <sqlite3.h> is included in the affected files.

Ah, the failing CI stuff for SQLite3 seems like an IWYU error. I'll ensure <sqlite3.h> is included in the affected files.

In relation to this is #include <sqlite3.h> no longer being done inside the sqlite_api namespace in include/soci/sqlite3/soci-sqlite3.h. I'm not entirely sure why having extern "C" decls in a namespace was the right move in 2006, given that these names can still be referred to unqualified (due to C linkage).

Either way, that means the sqlite3.h includes need to be as follows:

namespace sqlite_api
{

#include <sqlite3.h>

} // namespace sqlite_api

what is inconsistent about it now? I.e. what problem does this fix?

To me the inconsistency is when symbol visibility is applied. On Windows, SOCI_DLL is defined to achieve this, but it makes sense to me that when using the library as shared in general (where symbol visibility matter), SOCI_DLL being defined should be part of the usage requirements. This is also shown in the TnFOX example in the GCC visibility wiki.

FWIW this will create extra work for me

Sorry, was not aware of this :( But let me try my best to make some points.

what justifies spending extra time on this

It's pretty repetitive to have to manually #define a special symbol when building SOCI core or one of the backends. Although DEFINE_SYMBOL is CMake-specific, it mirrors a common practice in libraries that can be built static or shared in that for one of these flavors (typically shared, which is why I assume DEFINE_SYMBOL applies only the shared libraries), some macro is defined during compilation that adjusts the project-specific visibility macro being used to drive symbol export. curl has an example, albeit in reverse as generally it is used via the shared library instead of statically being linked.

I've gone back and thought about some things, and given how the SOCI_SOURCE and SOCI_<backend>_SOURCE macros have been originally used, I'll just consistently define these across static/shared builds. It will also rectify the situation going on with the soci-sqlite3.h header, and I can revert the #include-related commits I've made there.

Let me also address some of the code-related comments too.

Ugh... did not remove the SOCI_HAVE_VISIBILITY_SUPPORT check.

what is inconsistent about it now? I.e. what problem does this fix?

To me the inconsistency is when symbol visibility is applied. On Windows, SOCI_DLL is defined to achieve this, but it makes sense to me that when using the library as shared in general (where symbol visibility matter), SOCI_DLL being defined should be part of the usage requirements.

So let's just define SOCI_DLL when shared libraries are used and leave the rest alone?

It's pretty repetitive to have to manually #define a special symbol when building SOCI core or one of the backends.

But this is already done and new source files (let alone new backends) are not added very often. So as it is, this just creates extra code churn without any apparent gain.

To be fair, when adding new source files it can take quite some time to figure out that one has forgotten to define SOCI_SOURCE, especially given that this issue will only surface on Windows. So I do think that this counts as a streamlining of the buildsystem/build process and as such is valuable to have (as it decreases maintenance cost and/or reduces the barrier of entry for new developers).

BTW, compiling under Windows right now defines symbols like soci_postgresql_EXPORTS that comes from CMake itself (see DEFINE_SYMBOL). So maybe we don't need to define any symbols of our own. Although this one is defined for shared libraries only (but under all platforms).

streamlining of the buildsystem/build process

Yep, this was the overall intention. In general my opinion is that stuff like macros defined during compilation should be handled by the build system so one can focus on writing the code itself, especially the case of import/export visibility macros, as a separate SOCI_<backend>_SOURCE is needed for each backend beyond just SOCI_SOURCE for the core library.

BTW, compiling under Windows right now defines symbols like soci_postgresql_EXPORTS

Yes, so originally I was relying on DEFINE_SYMBOL, but I realized this leads to an issue with the sqlite3 backend that I mentioned in a previous comment. Because SOCI_SQLITE3_SOURCE controlled the namespaced inclusion of sqlite3.h, using DEFINE_SYMBOL to define it only during shared builds meant that I had to remove the conditional include from soci-sqlite3.h and then correctly do the namespaced include of sqlite3.h myself in several of the sqlite3 backend sources, i.e.

namespace sqlite_api
{

#include <sqlite3.h>

} // namespace sqlite_api

I think one decision that needs to be made is whether SOCI_SOURCE and SOCI_<backend>_SOURCE should be considered as a macro defined during compilation in general or only used for shared libraries to handle symbol visibility.

Sorry for complaining so much, but these CMake-related changes seem to be taking inordinate amount of the time which could (should?) be better spent on something more productive. It looks like 80% of the time I spend on SOCI is spent on struggling with CMake :-( And the Great CMake Rewrite didn't really improve this (I actually suspect the contrary, but maybe it's just because I'm particularly fed up with it right now).

I'll probably end up applying this because I don't want your work to go to waste, but I'd like to return to this a bit later, once I am capable of thinking about CMake-related issues without so much loathing again.

Sorry for complaining so much, but these CMake-related changes seem to be taking inordinate amount of the time

Haha, don't worry about it. CMake definitely helps with the messy reality of building C/C++ projects, but as much as I appreciate its usefulness, I also have moments where I wonder why some CMake things take so much work.

I'll probably end up applying this because I don't want your work to go to waste, but I'd like to return to this a bit later, once I am capable of thinking about CMake-related issues without so much loathing again.

No problem; I'll periodically keep the branch up-to-date with HEAD but won't be adding to it.

Hey, thanks for reviewing. I'm a bit busy right now due to some work-related things but I'll get back to this when I can.

I've looked at this again and this seems to be incomplete: if we remove, say, SOCI_FIREBIRD_SOURCE, we should remove the test for it in include/soci/firebird/soci-firebird.h and use SOCI_DECL instead of SOCI_FIREBIRD_DECL in this header etc (i.e. the same thing for all the other backends), shouldn't we?

Do you mean this part of the header?

If so, no; this should remain as-is. It's because when building as shared, each of the backends is built as a separate shared library. If, for example, they all used SOCI_DECL, which only marks symbols for export when SOCI_SOURCE is defined, and they all relied on SOCI_SOURCE being defined during compilation, then MSVC would incorrectly mark all SOCI_DECL symbols as being exported from all the backends too. The general rule is for each DLL being built, you need a unique import/export macro, which is controlled by a unique build-time macro when indicating symbols are being exported.

So in SOCI's case:

1. Each backend must have its own SOCI_<backend>_DECL visibility macro for symbol import/export
2. SOCI_<backend>_DECL must resolve on Windows to __declspec(dllexport) when SOCI_<backend>_SOURCE is defined
3. SOCI_<backend>_SOURCE is defined only during compilation for the given

This ensures that in the case of shared libraries being built, that for each backend, the corresponding SOCI_<backend>_DECL resolves to __declspec(dllimport) during compilation of any source not part of the backend library, while resolving to __declspec(dllexport) during compilation of any source that is part of the backend library.

Admittedly, the DLL design is a bit confusing at times. Although the idea of symbol visibility is good, the other option if not using the MSVC __declspec extension is to use a .def file, which is rather tedious to use.

Do you mean this part of the header?

Sorry, rather embarrassingly, I have to admit that I don't know what I meant any more :-( Maybe I wanted to use a single SOCI_BACKEND_DECL (with "BACKEND" being a literal string and not a placeholder) for all backends, but I'm not really sure and, anyhow, thinking about it again I don't see how is it really better than the current SOCI_${BACKEND}_DECL.

So this is probably fine as is, although I'm still not sure if this results in any real changes in behaviour: I see that we won't be using __attribute__ (( visibility("default") )) any more in static builds, but as these builds don't use hidden visibility by default anyhow, this probably doesn't change anything.

I'll try to update my own project build system to predefine SOCI_${BACKEND}_SOURCE and will merge this then.

I don't see how is it really better than the current SOCI_${BACKEND}_DECL.

Yeah, unfortunately every backend library needs its own SOCI_<BACKEND>_DECL.

I see that we won't be using __attribute__ (( visibility("default") )) any more in static builds

This shouldn't be an issue unless someone is trying to build a DSO using SOCI object files and for whatever reason relies on some SOCI symbols being visible by default when compiling with -fvisibility=hidden. But in that case, they would still need to build SOCI objects with -fPIC, and I don't think this is an expected or supported consumption pattern in most cases.

I'll try to update my own project build system to predefine SOCI_${BACKEND}_SOURCE and will merge this then.

Thanks for your patience!