Re: [CMake] ExternalProject_Add - Automatic Incremental Rebuilds + Add Sources to IDE
I finally got this working, including the sources from both projects and simultaneous building. It was simpler than I thought, and as similar to how you originally suggested. I created a superbuild CMakeLists.txt which just contains the add_subdirectory(libs) and add_subdirectory(apps). I reference the include directories for the libs headers by setting cache variable in the libs/CMakeLists.txt, which are then referenced in the apps/CMakeLists.txt . Since it's all together the targets from libs can be directly referenced when linking in apps. I'm not finished, but this method is already slick and straight forward. Our previous build system was based on plain makefiles with lots of edge cases, hardlinking, and referencing msvc7.0 via msys commandline flags (I know...). Thanks VERY much for cmake, our last build system was horrendous. I'm glad Sandia sponsors this. On Fri, Sep 20, 2013 at 12:45 PM, Aaron Nowack aaronbnow...@gmail.comwrote: You can structure the app CMakeLists such that it can reference the libs as part of a big build everything tree like this, or as something that has to be found with find_package, or as something you just point to with CMake variables. Was the parent CMakeLists.txt an example of only how to combine the sources, or should it be reasonably possible to do step-building? For example, I attempted the following... I've setup a parent CMakeLists.txt for the apps and libs as you described with subdirectories for apps and libs. I build the libs first, and have it set a variable of where the library will be installed to, named apps_lib_path. apps_lib_path is set with PARENT_SCOPE so it is passed into the apps/ directory. Now, in the apps folder I must reference to the library that libs will build. This seems to create a chicken-egg issue as I am trying to reference a library that isn't yet created. I am using find_package(libs) which checks several possible locations for the library, the first being apps_lib_path for the library libApps. Since no libApps is present (hasn't been built yet, still in the cmake stage) it is set to NOTFOUND and cmake returns an error. The best approach I've seen for this sort of thing so far is being used in the Open Cheimstry projects. They build and install everything as part of a super build into a known installation prefix in the super build build tree. Then, they use CMAKE_PREFIX_PATH and find_package to find *previously* built/installed sub-projects in subsequent sub-projects. Everything is built via ExternalProject there, but none of the individual projects build anything with ExternalProject -- they find everything with find_package. ( See their repos here: https://github.com/OpenChemistry-- the super build is in: https://github.com/OpenChemistry/openchemistry ) This is a great example, so they install into a common place where each project can use find_project(other_project) and link correctly. They force incremental rebuilds by using ExternalProject_Add_Step. Thanks for the help, - Aaron On Wed, Sep 18, 2013 at 8:51 AM, David Cole dlrd...@aol.com wrote: Ideally, for these rapid co-development phases I would like to a) Be able to rebuild a project using ExternalProject_Add whenever any source file changes. ExternalProject is not well suited for handling source level changes. b) Provide the mechanism for an IDE project to include all the sources from another project specified by ExternalProject_Add. Because of my answer for (a), I still don't think it's a good idea. For b) there was a bug open and closed here, http://www.cmake.org/Bug/view.**php?id=12322http://www.cmake.org/Bug/view.php?id=12322 I understand David's point about making bad assumptions, but I would find it extremely useful if I was able to include the sources and force a rebuild as I'm describing. I understand, and many others would also find it useful, but I doubt it can be done reliably. If somebody would like to prove me wrong, (on Windows with all supported versions of Visual Studio, and on the Mac with all versions of Xcode, and with Eclipse, and ...), I will gladly reverse my opinion. Does anyone have any ideas? We're currently doing a lot of refactoring on both repositories so removing as much development overhead will really help. When things get stable we will be using ExternalProject_Add on tagged revisions. The best solution for rapid co-development of multiple repositories is NOT to use ExternalProject. ExternalProject, as recently discussed in another mailing list thread here, is best suited for building static snapshots of repositories that do not change frequently. Does everything build with CMake? Good. Then you can make something like this work: # CMakeLists.txt cmake_minimum_required(VERSION 2.8.11) project(GlueLibsAndApp) add_subdirectory(libs) add_subdirectory(app) # Then, checkout the two separate repositories in libs and app
Re: [CMake] ExternalProject_Add - Automatic Incremental Rebuilds + Add Sources to IDE
You can structure the app CMakeLists such that it can reference the libs as part of a big build everything tree like this, or as something that has to be found with find_package, or as something you just point to with CMake variables. Was the parent CMakeLists.txt an example of only how to combine the sources, or should it be reasonably possible to do step-building? For example, I attempted the following... I've setup a parent CMakeLists.txt for the apps and libs as you described with subdirectories for apps and libs. I build the libs first, and have it set a variable of where the library will be installed to, named apps_lib_path. apps_lib_path is set with PARENT_SCOPE so it is passed into the apps/ directory. Now, in the apps folder I must reference to the library that libs will build. This seems to create a chicken-egg issue as I am trying to reference a library that isn't yet created. I am using find_package(libs) which checks several possible locations for the library, the first being apps_lib_path for the library libApps. Since no libApps is present (hasn't been built yet, still in the cmake stage) it is set to NOTFOUND and cmake returns an error. The best approach I've seen for this sort of thing so far is being used in the Open Cheimstry projects. They build and install everything as part of a super build into a known installation prefix in the super build build tree. Then, they use CMAKE_PREFIX_PATH and find_package to find *previously* built/installed sub-projects in subsequent sub-projects. Everything is built via ExternalProject there, but none of the individual projects build anything with ExternalProject -- they find everything with find_package. ( See their repos here: https://github.com/OpenChemistry -- the super build is in: https://github.com/OpenChemistry/openchemistry ) This is a great example, so they install into a common place where each project can use find_project(other_project) and link correctly. They force incremental rebuilds by using ExternalProject_Add_Step. Thanks for the help, - Aaron On Wed, Sep 18, 2013 at 8:51 AM, David Cole dlrd...@aol.com wrote: Ideally, for these rapid co-development phases I would like to a) Be able to rebuild a project using ExternalProject_Add whenever any source file changes. ExternalProject is not well suited for handling source level changes. b) Provide the mechanism for an IDE project to include all the sources from another project specified by ExternalProject_Add. Because of my answer for (a), I still don't think it's a good idea. For b) there was a bug open and closed here, http://www.cmake.org/Bug/view.**php?id=12322http://www.cmake.org/Bug/view.php?id=12322 I understand David's point about making bad assumptions, but I would find it extremely useful if I was able to include the sources and force a rebuild as I'm describing. I understand, and many others would also find it useful, but I doubt it can be done reliably. If somebody would like to prove me wrong, (on Windows with all supported versions of Visual Studio, and on the Mac with all versions of Xcode, and with Eclipse, and ...), I will gladly reverse my opinion. Does anyone have any ideas? We're currently doing a lot of refactoring on both repositories so removing as much development overhead will really help. When things get stable we will be using ExternalProject_Add on tagged revisions. The best solution for rapid co-development of multiple repositories is NOT to use ExternalProject. ExternalProject, as recently discussed in another mailing list thread here, is best suited for building static snapshots of repositories that do not change frequently. Does everything build with CMake? Good. Then you can make something like this work: # CMakeLists.txt cmake_minimum_required(VERSION 2.8.11) project(GlueLibsAndApp) add_subdirectory(libs) add_subdirectory(app) # Then, checkout the two separate repositories in libs and app and boom: all your sources for everything are all in the generated IDE project You can structure the app CMakeLists such that it can reference the libs as part of a big build everything tree like this, or as something that has to be found with find_package, or as something you just point to with CMake variables. Then later on, you can create a super build that builds both libs and app separately using ExternalProject, and have that app refer to the libs built in that manner, rather than as targets in the same CMakeLists directory structure. The best approach I've seen for this sort of thing so far is being used in the Open Cheimstry projects. They build and install everything as part of a super build into a known installation prefix in the super build build tree. Then, they use CMAKE_PREFIX_PATH and find_package to find *previously* built/installed sub-projects in subsequent sub-projects. Everything is built via ExternalProject there, but none of
Re: [CMake] ExternalProject_Add - Automatic Incremental Rebuilds + Add Sources to IDE
Ideally, for these rapid co-development phases I would like to a) Be able to rebuild a project using ExternalProject_Add whenever any source file changes. ExternalProject is not well suited for handling source level changes. b) Provide the mechanism for an IDE project to include all the sources from another project specified by ExternalProject_Add. Because of my answer for (a), I still don't think it's a good idea. For b) there was a bug open and closed here, http://www.cmake.org/Bug/view.php?id=12322 I understand David's point about making bad assumptions, but I would find it extremely useful if I was able to include the sources and force a rebuild as I'm describing. I understand, and many others would also find it useful, but I doubt it can be done reliably. If somebody would like to prove me wrong, (on Windows with all supported versions of Visual Studio, and on the Mac with all versions of Xcode, and with Eclipse, and ...), I will gladly reverse my opinion. Does anyone have any ideas? We're currently doing a lot of refactoring on both repositories so removing as much development overhead will really help. When things get stable we will be using ExternalProject_Add on tagged revisions. The best solution for rapid co-development of multiple repositories is NOT to use ExternalProject. ExternalProject, as recently discussed in another mailing list thread here, is best suited for building static snapshots of repositories that do not change frequently. Does everything build with CMake? Good. Then you can make something like this work: # CMakeLists.txt cmake_minimum_required(VERSION 2.8.11) project(GlueLibsAndApp) add_subdirectory(libs) add_subdirectory(app) # Then, checkout the two separate repositories in libs and app and boom: all your sources for everything are all in the generated IDE project You can structure the app CMakeLists such that it can reference the libs as part of a big build everything tree like this, or as something that has to be found with find_package, or as something you just point to with CMake variables. Then later on, you can create a super build that builds both libs and app separately using ExternalProject, and have that app refer to the libs built in that manner, rather than as targets in the same CMakeLists directory structure. The best approach I've seen for this sort of thing so far is being used in the Open Cheimstry projects. They build and install everything as part of a super build into a known installation prefix in the super build build tree. Then, they use CMAKE_PREFIX_PATH and find_package to find *previously* built/installed sub-projects in subsequent sub-projects. Everything is built via ExternalProject there, but none of the individual projects build anything with ExternalProject -- they find everything with find_package. ( See their repos here: https://github.com/OpenChemistry -- the super build is in: https://github.com/OpenChemistry/openchemistry ) HTH, David -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] ExternalProject_Add - Automatic Incremental Rebuilds + Add Sources to IDE
Hi, I am trying to figure out how to use externalproject_add to allow my work group to code more rapidly. We have a mercurial repository which builds a set of libraries, and a separate repository which contains applications that use those libraries. It is important for us to keep them separate. Currently, I use ExternalProject_Add in the application CMakeLists.txt file to build the libraries and install them to a local directory which the applications link to. This works great as long as I am _only_ working in the applications repository. If I need to work on the libraries repository I need to go through, navigate and edit the sources, build them myself, and have the applications repository point to the built libraries and test it. Ideally, for these rapid co-development phases I would like to a) Be able to rebuild a project using ExternalProject_Add whenever any source file changes. b) Provide the mechanism for an IDE project to include all the sources from another project specified by ExternalProject_Add. For b) there was a bug open and closed here, http://www.cmake.org/Bug/view.php?id=12322 I understand David's point about making bad assumptions, but I would find it extremely useful if I was able to include the sources and force a rebuild as I'm describing. Does anyone have any ideas? We're currently doing a lot of refactoring on both repositories so removing as much development overhead will really help. When things get stable we will be using ExternalProject_Add on tagged revisions. I highly appreciate any ideas, thanks. - Aaron -- 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://www.cmake.org/mailman/listinfo/cmake
