I am building a small utility library with c++ and thus far I have pretty much always consumed my libraries in place, i.e. they were always mixed with my actual code that consumes the library which means that header files could be reliably be located.
I am trying to get this cleaned up now by separating my code from the developed library and so I added an install target to my cmake file, this is all working (just for reference, the cmake file is below):
cmake_minimum_required(VERSION 3.16.0)
project(foo VERSION 1.0.0 LANGUAGES CXX)
add_library(${CMAKE_PROJECT_NAME} STATIC)
target_include_directories(${CMAKE_PROJECT_NAME} PRIVATE ${CMAKE_SOURCE_DIR})
add_subdirectory(src)
# install the library
include(GNUInstallDirs)
install(TARGETS ${CMAKE_PROJECT_NAME}
RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/${PROJECT_NAME}
)
And, for reference, within the src directory, there are CMakeLists.txt files for each source file in their own folder that add their relevant code to the target, which looks like this:
target_sources(${CMAKE_PROJECT_NAME} PRIVATE bar.cpp PUBLIC bar.hpp)
set_property(TARGET ${CMAKE_PROJECT_NAME} APPEND PROPERTY PUBLIC_HEADER ${CMAKE_CURRENT_SOURCE_DIR}/bar.hpp)
My project structure looks something like this:
project_root
└── src
├── dir1
│ └── dir2
│ └── bar.hpp
└── dir3
└── dir4
└── baz.hpp
Since I have added target_include_directories(${CMAKE_PROJECT_NAME} PRIVATE ${CMAKE_SOURCE_DIR}) to my top level CMakeLists.txt file, I can do include statements in my header files such as
// bar.hpp
#include "src/dir3/dir4/baz.hpp"
Now my problem starts when I am installing the library, all header files are essentially copied into the same directory, i.e. my directory structure for the header files now becomes
${CMAKE_INSTALL_PREFIX}
└── include
├── bar.hpp
└── baz.hpp
This will obviously break the library, as it is still trying to find baz.hpp in bar.hpp using the project's directory structure which was removed during the install step.
My question(s) thus is first more related to library design:
- What are common ways to organise header files after install? Is it common that the project directory structure is removed and header files now live all next to each other?
- If the above is true (or a common approach), how would one change the header files to remove the relative path?
I suppose the following answers are related but different (reasons provided in parenthesis):
- How replace string in a file with value of current directory using CMake (though this assumes that I have a *.hpp.in file in which I have specified cmake variables that are substituted, in my case all header files are actual code, not configuration files and I would like to keep it this way. I suppose this answer could be modified to replace strings in files?)
- CMake install header files and maintain directory hierarchy (this would work if I wanted to keep the directory structure, though for some reason I feel more gravitated towards having all header files side by side (as I only have about 5 header files, I feel it would be overkill to distribute them over several folders. For larger libraries this may make more sense)
- Installing C header files for libraries with many headers (well, this is specific for autotools (which I am trying to desparately avoid) and also there is no accepted answer, also this question is more aimed at a manual approach, I would like cmake to do all the heavy lifting for me)
- Distribution and Linking of C Header Files and Libraries (more of a basic question about libraries and header file distribution in general, my question is focused on cmake. I can easily solve this issue by manually editing files but want cmake to do that for me)
Related to my questions above, whenever I use external dependencies, it is common to include a single header such as #include <foo.hpp> which itself just collects include statements to the other header files such as
// foo.hpp
#include "bar.hpp"
#include "baz.hpp"
Of course I can manually create this file and copy it over as part of the installation process, but this fields wrong, this file ought to be generated by cmake based on the header files added to the project. I guess I am half way there, I am able to extract the header files as
set(HEADERS "")
get_target_property(TARGET_SOURCES ${CMAKE_PROJECT_NAME} SOURCES)
foreach(SOURCE ${TARGET_SOURCES})
get_filename_component(EXTENSION ${SOURCE} EXT)
if(EXTENSION STREQUAL ".hpp" OR EXTENSION STREQUAL ".h")
list(APPEND HEADERS ${SOURCE})
endif()
endforeach()
though at this point I am not sure if it is not just easier to write a small python utility script which can do all of the above quite well and without hassle or if it is worth bloating up my cmake file and let it handle everything (which feels more correct, but this is where I am at a loss due to lack of experience developing libraries and deploying them. I have looked around libraries I commonly use but they don't seem to enforce good software engineering practices (let's just say there is a lot of file globbing going on and I am pretty sure the cmake files I have looked at glorify the days before modern cmake came along, (you know, the good stuff, setting compiler flags within cmake ...).
