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 <[email protected]> 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 >
-- 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
