In the build directory, the build rules are generally like the would be in the source too... so you can just go into src/libwhatever and do 'make' in that branch. like if your target was visual studio or some IDE, you could click on a single project to build, and it would of course check and build related projects.
basically you don't even need ../ inclusions just a root that add_subdirectory( lib1 ) ... 2, 3, utils (which itself adds other utiliy thins that reference other lib targets )... On Mon, Oct 14, 2019 at 11:11 AM Fred Baksik <[email protected]> wrote: > > > On Mon, Oct 14, 2019, at 9:13 AM, David Aldrich wrote: > > Hi > > > > I am trying to convert a large software project from makefiles to CMake. > The project is organised as a set of shared ‘star’ libraries, linked to a > static ‘kernel’ library. The current directory arrangement is: > > > > |--stars > > | |-- star1_lib > > | |-- source files > > | |-- makefile > > | |-- star2_lib > > | |-- source files > > | |-- makefile > > | |-- solibs > > | |-- Release > > | |-- <star>.so files > > | > > |--kernel > > | |-- source files > > | |-- makefile > > | |-- Release > > | |-- kernel.a > > | > > |--application > > |-- makefile > > |-- Release > > |-- myapp.exe > > > > In high-level terms, how could I implement this using CMake, such that > invoking ‘make’ in directory ‘application’ invokes a make of each shared > and static library, and links them to form ‘myapp.exe’? > > > > (I understand the basics of CMake, the issue here is how to handle the > make of source code and libraries spread across a directory hierarchy). > > > > Best regards > > > > David > > > > add_subdirectory() can accept relative paths to outside the "root" source > tree. > So the main CMakeLists.txt would be located in ./application. > Then do: > add_subdirectory(../kernel kernel) > add_subdirectory(../stars/stars1_lib stars1_lib) > > ./kernel/CMakeLists.txt would list it's files, and etcetera. > > I've use this method in the past for handling applications that are meant > to target Windows, Linux, and embedded systems. > Then by using variables to determine with platform / target ertain kernel > and library characteristics are used. > Everything is built in the build directory for that particular platform / > target. > This allows for app_target1, app_target2, app_target3, ..., build > directories to be totally independent. > > -- > F > -- > > 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: > https://cmake.org/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: https://cmake.org/mailman/listinfo/cmake
