-
-
Notifications
You must be signed in to change notification settings - Fork 146
Adding a CMake interface library target #52
Comments
Hi @nyronium , thanks for the detailed description! I've tried to add a library definition as you've described, but I'm not really experienced with cmake so I'm not sure if it works as it should. Can you give it a try? It's only in master for now. |
@martinus Thanks for implementing this, I really appreciate it! Your changes are mostly fine, though there are just two small things that kind of prevent using your library properly. Both of them are easily fixed though. Wrong compile optiontarget_compile_features(robin_hood INTERFACE ${RH_cxx_standard}) This line breaks compilation, as it requests a feature called "14", which is not a thing. -target_compile_features(robin_hood INTERFACE ${RH_cxx_standard})
+target_compile_features(robin_hood INTERFACE cxx_std_14) cxx_std_14 is a compile_feature offered by cmake to require c++14 for your target. Global CMAKE stateset(CMAKE_CXX_STANDARD ${RH_cxx_standard})
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF) Setting global cmake variables is generally not a good practice, as it alters the global state for the whole project, not just for your definitions. In this case it will change the default standard for newly created targets, disable fallback to older standards and disable the use of any c++ extensions (such as gnu++14, ...). Either way you can (and should) completely delete these lines, and instead either use the exported target as a dependency in your test target, or alternatively you can simply replace FYI (CMake intro)I can understand that CMake does not seem very intuitive in the beginning, so Especially the paragraphs "Dos and Don'ts", and "How to structure your project" might provide some useful insights. I think adhering to some of those rules could both greatly simplify your setup and make it intuitive for other CMake users to use your project. Even in case you don't want to change your structure, it will certainly give you a good understanding of basic CMake and why things are usually done a certain way. I hope you'll find useful! |
Ok I think I got it now. I've got a minimal example in |
As this is a library, it would be awesome to add a library definition to the CMake target for easier inclusion in other projects. As usually, you can include libraries from a cloned repository with a single call to
add_subdirectory(external/somelibrary)
without also having it building tests or other binaries.If you like, I will gladly provide a PR for this. Though I must note that I'm not really familiar with your specific structuring of the CMake part. Therefore, I think it might be beneficial if you were to implement it, or first gave your opinion on some of the specifics.
Implementation
While ideally the library targets would also be used internally to "link" against the headers in all tests and examples, it can be considered a convention and thus is not strictly necessary.
Essentially it boils down to adding something along these lines to
CMakeLists.txt
(orsrc/CMakeLists.txt
depending on your conventions). I'm assumingrobin_hood
as a library name:In case you need a reference implementation for the CMake part, you can have a look at the
CMakeLists.txt
of other great header-only libraries like foonathan/type_safe, microsoft/GSL.If you do want to build binaries by default (probably useful when developing the library), but only when this project is NOT included by another project, it might be beneficial to use a master project detection like the following, and to initialize your options accordingly:
The text was updated successfully, but these errors were encountered: