Closed KerstinKeller closed 1 year ago
I honestly don't recall why there Celero forces static linkage. I would be happy to take a Pull Request if you have one.
Some improvements integrated into v2.8.4. Please provide a pull request if there are other suggestions here! The CMake methodology is a bit old at this point, so updates are welcome!
I also had linker errors when compiling and using celeoro v2.8.5 as static library. in my case ( using mingw) I needed to do
if(MINGW)
target_compile_definitions(${PROJECT_NAME} PRIVATE CELERO_STATIC)
endif(MINGW)
for the executable that links against static celero.
Apologies for that. I don't have a MinGW configuration to test with right now.
I am closing because the original issue has not been updated in over a year.
Hi thanks for this project!
I am trying to do a CMake build for an integration of Celero. I came across a few issues:
MT / MD Visual Studio
First question: why are you forcing a static linkage VS runtime linkage: https://github.com/DigitalInBlue/Celero/blob/9d0b1e8d77dd44b385591612a486e668a404d7b2/CMakeLists.txt#L46 ?
The CMake default is always
MD
and that has nothing to do with the question if I am building a shared or static library. So I would avoid coupling that to theCELERO_COMPILE_DYNAMIC_LIBRARIES
option altogether. It could be a completely separate option for the project in my point of view, and please don't makeMT
the default.(actually you can pass it also from outside via
CMAKE_MSVC_RUNTIME_LIBRARY
andCMP0091
, see here which I would recommend a hundred times over forcing it on the user)Generated Config files
The following line causes the generated
celero-config.cmake
file not to be relocatable: https://github.com/DigitalInBlue/Celero/blob/9d0b1e8d77dd44b385591612a486e668a404d7b2/CMakeLists.txt#L209-L213The following code is generated by CMake:
Instead, you should omit the `CMAKE_INSTALL_PREFIX``
Exporting targets to a namespace
It's CMake best practice to export targets to a namespace. (e.g. to reference the celero library from CMake as
celero::celero
instead of onlycelero
. It does have some CMake advantages (e.g. it's recognized as a target, and not acidentially mistaken as a linker command). However it might break users who are already consuming the celero library.Warning / build errors when linking static library:
Lastly, I am also getting these warnings (and respective error messages) when compiling a sample against the build static libraries. (I am building one of the samples
and then a bunch of unresolved external errors
Do I need to take explicit care when linking celero as a static library?
I'd be happy to create a PR for the first issues. Please let me know if you are interested.