[CMake] Organization of larger projects

[J Decker]

add_subdirectory works for any subdirectroy... just if it's above your
start point, you need to specify an additional name to mount the subdir as
in the cmake_binary_dir...

add_subdirectory( ../libs/widgets widgets )

the problem can be that you end up including  the same subdirectory twice
as two different target paths; then you'll get warnings about dupilicate
definition and have to test like if( NOT TARGET <target> ) ..<cmake include
file>.. endif()



On Sat, Nov 29, 2014 at 6:44 AM, Paul Anton Letnes <pa at letnes.com> wrote:

> 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
>
> --
>
> 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/20141130/39db195e/attachment.html>