`reflect-cpp` does not generate `.lib` file when building as `shared` on Windows

[ErniGH]

When building the library on Windows in shared mode, no symbols are exported and the corresponding .lib file is not generated.

I built it using Conan, and as you can see here the .lib file is not generated:

C:/Users/ernesto/.conan2/p/b/refle6511ce2ce100d/p/lib/cmake/reflectcpp/reflectcpp-exports-release.cmake

reflect-cpp/0.19.0: package(): Packaged 1 '.dll' file: reflectcpp.dll
reflect-cpp/0.19.0: package(): Packaged 376 '.hpp' files
reflect-cpp/0.19.0: package(): Packaged 1 '.h' file: yyjson.h
reflect-cpp/0.19.0: package(): Packaged 1 file: LICENSE
reflect-cpp/0.19.0: Created package revision 09f5cceb5cba84250c48638d6b04e5e5
reflect-cpp/0.19.0: Package 'a5d8167e60ca3058a0934e27117193e1e9ea29c2' created
reflect-cpp/0.19.0: Full package reference: reflect-cpp/0.19.0#613991dd09c0fb51a26864aab6ffed46:a5d8167e60ca305
```
Here you can find the full log:
[reflect-cpp.log](https://github.com/user-attachments/files/22882415/reflect-cpp.log)

[BestITUserEUW]

@ErniGH Shared libraries on windows are called .dll and .lib are static ones. So that there is no .lib created makes sense as you requested a shared build. If you really want a static library set REFLECTCPP_BUILD_SHARED=OFF when running cmake.

static libraries

[ErniGH]

Hello, thank you for your response. When you dynamically link a library in Windows, you don't just need the DLLs — Windows also uses the .lib file to link the application. In both shared and static linking, .lib files are used: in static, they contain the library itself, and in shared, they assist with the linking process.

In load-time dynamic linking, an application makes explicit calls to exported DLL functions like local 
functions. To use load-time dynamic linking, provide a header (.h) file and an import library (.lib) file 
when you compile and link the application. When you do this, the linker will provide the system with 
the information that is required to load the DLL and resolve the exported DLL function locations at
load time.

https://learn.microsoft.com/en-us/troubleshoot/windows-client/setup-upgrade-and-drivers/dynamic-link-library#load-time-dynamic-linking

The idea behind using those .lib files in the shared context is to avoid having to manually load the symbols using the Windows API.
https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya

[BestITUserEUW]

@ErniGH I yield to your superior knowledge.

Thanks for the clarification. Seems like spdlog does that correctly by declaring a SPDLOG_API macro. So essentially marking the public api with RELFECT_CPP_API which is a dllimport in shared msvc mode and when building the project adding a REFLECT_CPP_EXPORT to the compile definitions so REFLECT_CPP_API becomes a dllexport ?

[BestITUserEUW]

@liuzicheng1987 Are you interested in adding this to your library ?

[liuzicheng1987]

@BestITUserEUW , absolutely. If you want to do this, go ahead.

[BestITUserEUW]

@liuzicheng1987 I’ll first try it on my own library to see how it works correctly, and then I’ll do it here. I’ll probably have time for it over the weekend, but it sounds like a nice task.

[ErniGH]

Hello @BestITUserEUW, I’ve made a patch that can help show how to generate the header and the .lib so it can be used. Below, I explain the process step by step:

First, we generate the macro. Instead of hardcoding it like spdlog does, we can use the CMake macro:

@@ -155,6 +155,10 @@ endif()
 
 add_library(reflectcpp::reflectcpp ALIAS reflectcpp)
 
+include(GenerateExportHeader)
+generate_export_header(${PROJECT_NAME}
+    EXPORT_FILE_NAME include/rfl/reflectcpp_export.hpp)
+

We specify to CMake where to find that header:

@@ -192,6 +196,10 @@ target_include_directories(
     $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
     $<INSTALL_INTERFACE:include>)
 
+target_include_directories(
+    reflectcpp PUBLIC
+    $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/include>)
+

And we make CMake copy the file during the build:

@@ -410,6 +418,9 @@ if (REFLECTCPP_INSTALL)
         BASE_DIRS $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include> $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/include>
         FILES ${RFL_HEADERS})
 
+    install(FILES ${CMAKE_CURRENT_BINARY_DIR}/include/rfl/reflectcpp_export.hpp
+        DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/rfl)
+

Now we add this reflectcpp_export.hpp to rfl.hpp to include our new header. I haven’t kept alphabetical order since it could cause problems with files included before this one, for example Generic.hpp:

@@ -7,6 +7,9 @@
 #pragma warning(disable : 4101)
 #endif
 
+
+#include "rfl/reflectcpp_export.hpp"
+
 #include "rfl/AddStructName.hpp"
 #include "rfl/AddTagsToVariants.hpp"
 #include "rfl/AllOf.hpp"

Finally, we need to add the REFLECTCPP_EXPORT keyword to all classes and methods we want to export. In my example, I add it to Generic, Type, Reader, and Writer. But this is incomplete — I need your help to complete the list of all symbols that need to be exported for proper use of the library:

class REFLECTCPP_EXPORT Generic
...
REFLECTCPP_EXPORT Type with_name(const std::string& _name) const;
...
struct REFLECTCPP_EXPORT Reader {
...
class REFLECTCPP_EXPORT Writer {

Find here the patch and also the build.log on Windows building as shared
As you can see the .lib has been generated:

...
reflect-cpp/last: package(): Packaged 1 '.dll' file: reflectcpp.dll
reflect-cpp/last: package(): Packaged 426 '.hpp' files
reflect-cpp/last: package(): Packaged 1 '.h' file: yyjson.h
reflect-cpp/last: package(): Packaged 1 '.lib' file: reflectcpp.lib    <===
reflect-cpp/last: package(): Packaged 1 file: LICENSE
...

windows-shared-build.log
generate-lib-file.patch

[BestITUserEUW]

@ErniGH I did some additional research on this yesterday, and it seems that exporting is only necessary for components compiled into the shared library — which makes sense. Therefore, there’s no need to export the header-only parts since those don’t need to be imported from the library. (Except for precompiled variants)

A working example can be found here: chron-cpp.
I'll have a look at generate_export_header.

Correct me if i am wrong but struct REFLECTCPP_EXPORT Reader rfl::json::Reader will never end up in a compiled version in the library so this is an unnecessary export / import here.

[BestITUserEUW]

The #include "rfl/reflectcpp_export.hpp" inside rfl.hpp won’t work.

As soon as someone includes a header like <rfl/json/write.hpp>, which possibly includes something using the REFLECTCPP_API export macro, it won’t be defined — resulting in a compiler error.

So, I think the correct approach is for each file that uses this macro to include the export header itself.

Now there’s a second issue: rfl only allows relative includes, which we can’t really use for generated headers.
Something like #include "../../reflectcpp_export.hpp" won’t work.

Alright, so let’s just use #include "rfl/reflectcpp_export.hpp" instead.
Nope — the relative include checker doesn’t like that either which is understandable:

Non-relative include of rfl/reflectcpp_export.hpp @ ./rfl/Generic.hpp:14
Non-relative include of rfl/reflectcpp_export.hpp @ ./rfl/json/Writer.hpp:16
Non-relative include of rfl/reflectcpp_export.hpp @ ./rfl/avro/schema/Type.hpp:13

So my proposed solution is to simply define the macro ourselves. It’s such a trivial file that it could just look like this:

#ifdef REFLECTCPP_BUILD_SHARED
#ifdef _WIN32
#ifdef reflectcpp_EXPORTS
#define REFLECTCPP_API __declspec(dllexport)
#else
#define REFLECTCPP_API __declspec(dllimport)
#endif
#else
#define REFLECTCPP_API attribute((visibility("default")))
#endif
#else
#define REFLECTCPP_API
#endif

This is more simple + easier to reason about when working on this project + does not mess with rfl`s include philosophy. This only requires adding the following line to CMake:

target_compile_definitions(reflectcpp PUBLIC REFLECTCPP_BUILD_SHARED)

CMake generates some additional stuff like NO_EXPORT and DEPRECREATED. NO_EXPORT would be two additional lines to this file if needed at one point and for deprecations just use attribute specifiers

Sadly i was not able to just: I need your help to complete the list of all symbols that need to be exported for proper use of the library

@liuzicheng1987 Are you okay with this approach instead of using generate_export_header ?

[liuzicheng1987]

@BestITUserEUW , sounds like a great solution. Thank you so much!

@ErniGH , thank you as well for raising the issue and proposing a solution!

[liuzicheng1987]

@ErniGH , once we have this implemented should we do a patch release to be used by Conan? Should we do the same thing for sqlgen (that's how this all got started after all...)?

[ErniGH]

@liuzicheng1987 Yes, it would be great to add a new release with these changes. As for sqlgen, if it has the same issue, it should be fixed as well

[liuzicheng1987]

@ErniGH ， I'll take care of it.