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
