How about something like (in the top-level directory for the projectlib
sources):
add_library(projectlib STATIC projectlib/foo.h projectlib/foo.cpp ...)
target_include_directories(projectlib PUBLIC . PRIVATE projectlib)
(Note that this will add the top-level directory as well as the projectlib
subdirectory for building projectlib sources - which is probably what you want
in order to be able to resolve inter-header dependencies.)
--
Daniel Schepler
________________________________
From: CMake [cmake-boun...@cmake.org] on behalf of Chris Johnson
[cxjohn...@gmail.com]
Sent: Monday, January 19, 2015 5:14 PM
To: cmake@cmake.org
Subject: [CMake] Library include path question
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
