On 7 July 2011 15:15, David Cole <david.c...@kitware.com> wrote: > > I'm sure that what you want to do is possible. I'm also sure that it's a > huge effort to get it to work with all CMake generators. It will also be > difficult to write a good test of the functionality. > > Furthermore, I view it as largely unnecessary work... > > ...because a full file-system-level clean of deleting the entire build > tree, followed by a quick configure with CMake of the top level project, > followed by a regular build has largely the same net result with negligible > difference in total build time. If the difference in total build time is > non-negligible, and really annoying to somebody, then this huge effort may > well be worth it to them, at that point in time. > > Right now, I'm not convinced the extra effort and extra complications in > the code are worthwhile additions to CMake. >
I understand where you're coming from on the resources front. There would obviously be some effort required to get this to work properly. I'm not convinced it is such a huge amount of work as you're suggesting, but then I don't know the source code as well as you do :-) >From my point of view this does make using ExternalProject_Add() a less interesting option. Yes, I can tell users that they have to manually delete a sub-tree and re-run the configure step and then rebuild the top level project. But realistically that isn't going to fly for the majority of users, especially the Visual Studio users. They just want to select build, or rebuild and expect it to work. If I get some spare time I will investigate further what would be involved. -- Glenn
_______________________________________________ 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
