[CMake] Library include path question

[Roman Bolshakov]

We use similar layout in a set of components, but in order to do that we just store library interface headers in <lib-name>/include/<lib-name> directory. And layout of library directory is the following:
src/  - internal headers and implementation
include/ - external headers
CMakeLists.txt

Then you can define the following to expose the directory for clients of the library within the same CMake project:
target_include_directories(<lib-name>
    PRIVATE src
    PUBLIC include
)


Another way to achieve that is to expose library's parent directory as include interface. That's a case if all your sources, external and internal headers are stored under the library directory:
get_filename_component(PARENT_DIR ${CMAKE_CURRENT_SOURCE_DIR} DIRECTORY)

target_include_directories(<lib-name>
    INTEFACE ${PARENT_DIR}
)

As downside, that would make all headers (even internal) visible to the clients of the library.


If you have two separate CMake projects (i.e. two git repos) you can change layout of the headers on install step without changing anything in source tree.
e.g. we have external and internal headers in src directory:
target_include_directories(<lib-name>
    PRIVATE "$<BUILD_INTERFACE:src>"
    INTERFACE "$<INSTALL_INTERFACE:include/<lib-name>>"
)

install (FILES src/foo.h
                       src/bar.h
           DESTINATION include/<lib-name>
           COMPONENT devel
)


In all the cases, I assume usage requirements model (target_link_libraries) is used for consumption of the library.

-Roman

> 20 янв. 2015 г., в 4:14, Chris Johnson <cxjohnson at gmail.com> написал(а):
> 
> A common and useful method for avoiding name conflicts and keeping files well-organized is to place them in a subdirectory unique to the library.  For example, the libraries for Graphviz and Postgres often install their API header files in directories named <install-prefix>/include/graphviz and <install-prefix>/include/libpq.  So on my local development system, these libraries' API header files are in /usr/local/include/graphviz/*.h and /usr/local/include/libpq/*.h.
> 
> This is the convention that we use for our internal projects as well.
> 
> C++ code which needs to include these files by necessity must name that subdirectory.  For example, to use Postgres's API defined in libpq-fs.h, the C++ code must look like this:
> 
> #include <libpq/libpq-fs.h>
> 
> We do the same for our internal libraries, for example, to use the "projectlib" library from some program, the code would resemble:
> 
> #include <projectlib/foo.h>
> 
> In the library itself, however, the code is like this:
> 
> foo.h:
> -----
> class Foo {
> public:
>     Foo();
> };
> 
> foo.cpp
> -------
> #include "foo.h"
> 
> Foo::Foo() {
>  // constructor code
> }
> // etc.
> 
> That is, note that the header and source files are in the SAME directory.
> 
> 
> CMake does not handle this well when trying to compile a program using the library.  CMake wants to look in the source directory or the build directory for the header file, and those directory paths do not have the "projectlib" prefix which is what the source code for the program expects (#include <projectlib/foo.h>).
> 
> I've kludged around this by adding a function which does some ugly directory creation in the build directory and then copies the headers to where the source expects to find them.
> 
> But I think there's something about CMake I am not understanding correctly, or a feature I should be using that I am unaware of, in order to make this all work without writing code in my CMakeLists.txt files to copy source files to expected places.  This library file layout for headers and source is very common in the Unix world, and we've modeled our largish (500 directories, dozens of libraries) project on it.
> 
> Is there something about CMake I need to learn to make this work more cleanly?
> 
> 
> Thanks,
> ..chris
> 
> 
> 
> 
> 
> 
> Most libraries correctly put their headers into ./include/<libdirname> 
>  	39	# but CMake wants to look in the source or build dir, which doesn't have 
>  	40	# <libdirname> as a prefix. That prefix is used in the source files in  
>  	41	# their #include "libdirname/libheader.h" statements.  Headers will not be 
>  	42	# found with that prefix when obtained from the source or build dir by CMake. 
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150120/938ff200/attachment.html>