CODEWITHSUNDEEP
c++cmake
Omnifarious
Omnifarious

Reputation: 56038

Library with sub-libraries and include directories, how do I do it in CMake?

I have a project structured in this way:

project
 |\_subdir
 |   | Some .cxx files
 |   | some .h files (included with #include "foo.h"
 |    \_subdir
 |       | Some .h files (included with #include <subdir/foo.h>)
  \_subdir2
     | some .cxx files
     | some .h files (included with #include "foo.h"
      \_subdir2
         | Some .h files (included with #include <subdir2/foo.h>)

I need to do a few things here:

  1. The subdir/subdir directories should be publicly available for use in programs that use this library with #include <subdir/foo.h>.
  2. The subdir directories should produce their own statically linked libraries so that I can run tests making sure that the dependency relationships between the different subdir directories are maintained.
  3. The whole thing should produce either a shared or static library that has everything in all the subdir directories and can be linked to by programs using this library.

Currently I have a build system that I've made using autotools (but not automake) plus some custom made perl scripts that process the dependency output from the -M flags and create custom makefiles that express dependency information. Additionally, they create an include directory that's a linkfarm so everybody can use #include <subdir/foo.h> and just -I the linkfarm directory.

I want to convert this to CMake, but I'm at a loss as to how to handle the subdir structure and includes. I can re-arrange the directory structure somewhat if absolutely necessary, but I would very much like to preserve the pseudo-independence of the various subdir directories, partly because it's very important to me to be able to make sure the sub-libraries have a specific dependency relationship as a way to maintain modularity and cleanliness.

How would I do this in CMake? Do I have move the subdir/subdir directories?

Because it looks like if I add the subdir directories as a public include, then things will go really awry as people will see the private .h files at the subdir level as well as being able to include the .cxx files that are in them. Even worse, they will see them as top-level includes (i.e. #include <bar.cxx> where bar.cxx is a private implementation file who's object code should already be in a library).

But if add subdir/subdir as an include directory, the .h files won't appear in subdirectories like they should (i.e. #include <subdir/public.h> won't work, instead I'll have to use #include <public.h> which isn't my intent at all).

Upvotes: 2

Views: 444

Answers (1)

Tsyvarev
Tsyvarev

Reputation: 65870

If you bother about users of your library, they will see installed files, not ones in the source/build directories. If you don't install private headers (from subdir/), a user won't see them.

But if you do not intend to install library, then you may separate public and private include trees. E.g. each project may have private headers directly in its source directory, and public headers under its include/ subdirectory:

  project
 |\_subdir
 |   | Some .cxx files
 |   | Private .h files (included with #include "foo.h")
 |    \_include (public include directory)
 |       \_subdir
 |         | Public .h files (included with #include <subdir/foo.h>)
  \_subdir2
     | some .cxx files
     | Private .h files (included with #include "foo.h")
      \_include (public include directory)
         \_subdir2
           | Public .h files (included with #include <subdir2/foo.h>)

Upvotes: 2

Related Questions