Good ideas. Perhaps beyond the scope of our little CMake module named ExternalProject, but definitely good ideas.
It starts to approach the capabilities of a full blown package manager with version and dependency management features. And I think that is quite beyond the scope... ExternalProject is offered as a convenient way to build stuff. It leaves the onus on the SuperBuild creator to specify things exactly as needed for combining multiple projects into something useful. Part of that is understanding how to build each sub-component and what its requirements are. ExternalProject helps to codify that in SuperBuild CMakeLists files, but it does not have a full understanding, leaving that to the smart people who are creating SuperBuilds. If you are tracking something live (origin/master of some git repo) then you have to notice when requirements for that thing change... and adapt to the new requirements. I definitely do NOT see ExternalProject growing into a full blown package management system: it's a convenience mechanism that helps you construct a system from pieces, but nothing more. I'm always open to suggestions and patches, though. I would just hate to see it become hopelessly complicated. (It's already pretty complex...) David On Wed, Mar 21, 2012 at 2:40 PM, Danielle Pace <[email protected]> wrote: > Clarification - this is because we are tracking CTK's master branch - you > wouldn't see this problem if you fixed your dependency to be a specific > release/git commit. > > -Danielle > > > On Wed, Mar 21, 2012 at 2:26 PM, Danielle Pace <[email protected]> > wrote: >> >> Hi all, >> >> An idea for future cmake improvements - >> >> We ran into an issue on one of the open-source toolkits I'm working on >> (Tubetk, http://public.kitware.com/Wiki/TubeTK). TubeTK uses superbuild >> (ExternalProject_Add) to handle a dependency on CTK, which in turn requires >> CMake 2.8.4. However, the TubeTK requirements were not kept in sync (was >> set to require CMake 2.8). >> >> On a dashboard machine with CMake < 2.8.4, this gives a somewhat cryptic >> error message related to CTK, but not referencing the root problem with >> CMake: >> https://www.kitware.com/CDash/viewConfigure.php?buildid=197007 >> Such an error message would be very confusing for end-users. >> >> Of course, the fix is to manually change a project's requirements whenever >> a dependency's requirements change, but this is somewhat annoying. >> >> Has anyone given any thought to automatic integration of requirements >> across dependencies? Ex. if dependency A requires CMake 2.8.4, dependency B >> requires CMake 2.8.2, and the main project requires CMake 2.8, the actual >> requirement is CMake 2.8.4. Besides this particular example with >> cmake_minimum_required, it would be super cool if this kind of thing could >> work with other dependencies, ex. versions of Qt. >> >> Best, >> >> Danielle >> >> -- >> Danielle Pace, M.ESc. >> Research and Development Engineer >> Kitware Inc., >> North Carolina Office >> >> www.kitware.com >> 919-969-6990 X 319 >> > > > > -- > Danielle Pace, M.ESc. > Research and Development Engineer > Kitware Inc., > North Carolina Office > > www.kitware.com > 919-969-6990 X 319 > > > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
