Fix Shared library export and don't install GTEST#245
Fix Shared library export and don't install GTEST#245damiandixon wants to merge 14 commits intoAngusJohnson:mainfrom
Conversation
Build libraries as shared. Hide classes and methods not exported or fully defined in headers
Set default build to Release
|
To get around the issue with the current build you will need to either disable the C4251 warning or prohibit the windows build from building a shared library. To disable the C4251 warning you will need to sprinkle code like this throughout the code base inside class/struct declarations: Here is a diff that fixes it: |
| option(CLIPPER2_EXAMPLES "Build examples" ON) | ||
| option(CLIPPER2_TESTS "Build tests" ON) | ||
|
|
||
| set(CMAKE_CONFIGURATION_TYPES "Debug;Release;RelWithDebInfo" CACHE STRING "Configs" FORCE) |
There was a problem hiding this comment.
Please don't force the value of this variable, as this can disrupt projects including Clipper2 as a subproject.
|
|
||
| set(CMAKE_CONFIGURATION_TYPES "Debug;Release;RelWithDebInfo" CACHE STRING "Configs" FORCE) | ||
| if(DEFINED CMAKE_BUILD_TYPE) | ||
| SET_PROPERTY(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS ${CMAKE_CONFIGURATION_TYPES}) |
CPP/CMakeLists.txt
Outdated
| # 2d version of Clipper2 | ||
| add_library(Clipper2 STATIC ${CLIPPER2_INC} ${CLIPPER2_SRC}) | ||
|
|
||
| add_library(Clipper2 SHARED ${CLIPPER2_INC} ${CLIPPER2_SRC}) |
There was a problem hiding this comment.
It is preferable to omit SHARED or STATIC altogether and let CMake generate a static/shared library based on the value of the BUILD_SHARED option (set by the user).
| * License : http://www.boost.org/LICENSE_1_0.txt * | ||
| *******************************************************************************/ | ||
|
|
||
| #ifndef CLIPPER2_DLL |
There was a problem hiding this comment.
Consider using https://cmake.org/cmake/help/latest/module/GenerateExportHeader.html rather than defining this by hand (provides flexibility for both static/shared libs with the same CMake target).
There was a problem hiding this comment.
I was not aware of this. Tx.
I'm wondering if exporting classes is the best approach for DLLs? |
Personally, I would prefer to keep the classes. All shared libraries in C++ bump into this in one form or another. |
…and_shared_lib_linux
Clean up target properties
Provides versioning and install of headers.
I appreciate that exporting C++ classes may be very useful in Linux, but ISTM that it's discouraged in Windows. |
| # define CLIPPER2_DLL | ||
| # else | ||
| # if __GNUC__ >= 4 | ||
| # define CLIPPER2_DLL __attribute__((visibility("default"))) |
There was a problem hiding this comment.
CLIPPER2_DLL is a misleading name, since it's designed to be cross-platform. Usually it's called <LIB>_API or <LIB>_EXPORT
There was a problem hiding this comment.
I'd be happy to rename it CLIPPER2_EXPORT if there's concensus with that.
Edit: And presumably the file would be clipper.export.h .
The shared library export fix is detailed in #244 for non Windows only.
This adds the CLIPPER2_DLL to all classes and methods that are in the headers that have a cpp implementation.
The CMakeLists.txt is updated to ensure that the exports are exported.
The libraries are built so that symbols are hidden unless exported.
Additional updates in CMakeLists.txt:
This leaves the Windows build as a static library.
The default on Linux is a Shared library.
This is a work in progress.