[CMake] Organization of larger projects

[Paul Anton Letnes]

Hello, list!

A bit of background: I am currently working inside a large perforce repository, containing source code for several programs. Some functionality has been separated out into separate directories, e.g., some linear algebra operations, file I/O, etc. Currently, all programs (save for one, which I've CMakeified) build by Makefiles, which basically list all source files, residing in all sorts of directories scattered around the repository. An abbreviated example file structure could be
-- root
|-- category-1
| |-- somelib
| | `-- foo.f
| `-- someprogram
| |-- main.f
| `-- Makefile
`-- category-2
|-- otherlib
| `-- bar.f
`-- otherprogram
|-- main.f
`-- Makefile

Every Makefile can, conceivably, shop any number of files from any "library" directory, using the "add_executable (target file1 file2 ...)" type of logic.

I've managed to CMakeify one of these programs, basically, by listing all the source files and having CMake link them together. I would, however, prefer to create modules/libraries in some sense. My initial idea is that "otherlib" and "somelib" could be built into static libraries "on the fly", but by a CMakeLists.txt in each directory. The "add_subdirectory" command comes to mind, but it does not work for directories that are not actual subdirectories in the filesystem. I've been playing with the idea of using Externalproject_add commands or custom find_package, but these seem to be geared towards globally installed libraries, which I do not want (yet, at least). The reasons for the project organization is of cource "history" and "legacy" much more than anything else, and with several applications and "libraries" mixed together, it's a challenge to refactor both build systems and code into a more sensible architecture.

What do you recommend in this case?

I would highly prefer not creating static libraries outside the build system, since in this case, the combinatorics make for a lot of pre-built libraries - one per 32/64 bit, operating system, and across 3-4 compilers...

-----------
Paul Anton Letnes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141129/4b2d8372/attachment.html>