fix decl specs for static build

[kateyy]

This uses the generate_export_header function introduced in CMake 2.8.6, simplifying the dll export/import/static build switch.

It's only tested on MSVC.

[sbusch42]

Crucial points missing in this pull request:

• A description of what was actually wrong with the current approach. Why was this done? Is the change just because "this approach is better/modern/I like it more", or is there anything actually wrong or missing in the current approach?
• A discussion in advance about whether we want to do it this way or not. This is an important change, those things should be discussed.
• If we should agree on such a change, it should be done in all of our interdependent projects, starting with cmake-init, not just in libzeug.

So, any thoughts on this one?

[kateyy]

Yep, I could have been more verbose about the PR, sorry for that.

Currently, static build does not work with Visual Studio (OPTION_BUILD_STATIC checked in CMake). The *ZEUG_EXPORTS are defined to __declspec(dllimport) when compiling or including the libraries. This breaks the build (dllimport not allowed for static data member etc), and is not needed when linking static libraries.

The obvious solution would be adding another condition to the *zeug_api.h files. CMake generated export headers will do that for us. This way we can build on a working implementation, removing redundant code, which is, I think, less error-prone.

The api import/export headers in cmake-init also contain definitions for debugging and exception handling. We can't include that in the CMake-generated files, but it seems not to be needed in libzeug. To either we fix our own api headers and use them for all projects, or use the CMake generated headers at least where possible. Yep, I could have been more verbose about the PR, sorry for that.

Currently, static build does not work with Visual Studio (OPTION_BUILD_STATIC checked in CMake). The *ZEUG_EXPORTS are defined to __declspec(dllimport) when compiling or including the libraries. This breaks the build (dllimport not allowed for static data member etc), and is not needed when linking static libraries.

The obvious solution would be adding another condition to the *zeug_api.h files. CMake generated export headers will do that for us. This way we can build on a working implementation, removing redundant code, which is, I think, less error-prone.

The api import/export headers in cmake-init also contain definitions for debugging and exception handling. We can't include that in the CMake-generated files, but it seems not to be needed in libzeug. -fvisibility=hidden for gcc is also supported by the CMake command, but is not included in my proposed solution.

So either we fix our own api headers and use them for all projects, or use the CMake generated headers where possible.

[cgcostume]

api headers of cmake init were already fixed for this (it was just not applied to libzeug - sorry) - furthermore, cmake-init just got refined concerning static linking.

design decision for now is to not use generate_export_header based on the following remarks:

• having a generator specific api include in our released versions hinders to rebuild and reuse it with other generators, since it is more complicated for devs to (1) cope with the cmake generation of files in some build folders, (2) as well as the concept of a single api header or conf header as common for small c++ libs,
• all hpicgs libs are mainly intended / per default setup to be used and released as dynamic libs. having a static release requires either to deploy an adjusted header or two different versions for it, or as it is the case for cmake-init an preprocessor define before including the api

to conclude:

• favor a single api/export header for all systems/generators that allows for project specific adjustments and requires no additional knowledge about cmake/code generation/templates etc..
• it is the known/common way for used by most other well-known 3rd party libaries to require a define ... for static linking
• static linking is not suggested, thus should provide the only overhead, if any, at all. dynamic linking is default and should work as expected out of the box
• even though, releases containing both versions (static and shared) are not provided, intended, or required yet; any cmake-init based project could easily provide this without any restructuring (since only a single def is required for the linking project)

The only nice solution would be to let the config-cmake know what kind of linking is specified and provide the appropriate definition used in the include. This issue however, is known to the cmake community and afaik not solved/apporached yet.

I would suggest to close the pull request without merge.

[cgcostume]

ah, forgot: instead apply cmake-init way to libzeug

[kateyy]

yep okay, so let's wait for the fixes from cmake-init