On Tue, Feb 26, 2013 at 4:50 PM, Brad King <[email protected]> wrote: > On 2/26/2013 2:52 PM, Jean-Christophe Fillion-Robin wrote: >> +1 to add these into CTest :) What would be the argument against it ? > > Not every project wants every submodule checked out all the time. > A major use case for them is to have an umbrella project with many > submodules and the developer may only checkout and work on some. > Some may even be proprietary and inaccessible to some machines.
Agreed, there are different uses for submodules but it seems like we are also neglecting a common use case. > >> > However, it seems to me that ctest already does a >> > git submodule update --recurse > > This is the proper command to update everything that is already > to configured to checkout in the source tree. > >> > but its missing the --init flag to deal with changes to the >> > .gitmodules file. >> It also misses git submodule sync to deal with changes in git >> submodule URL, > > These are all intentionally missing for the above reason. We > should honor the user's configuration. Maybe they intentionally > use a custom url for a submodule for the branch they test. We > should not blow away their configuration by default. > >> and reset --hard etc. > > We do a reset --hard at the top level but I do not think we > do it in the submodules. That may be worth adding, perhaps > with git submodule foreach. This would be very helpful, and is a big inconsistency in the current behavior. > >> We have just been dealing with a >> few of these issues and currently call git directly to sync, init, and >> then use submodule foreach to reset and clean all submodules before >> updating. > > That is the expected way to deal with it. The local dashboard > script knows if it needs to preserve the user config or not. > > We could also consider adding options for ctest_update to > tell it to init, sync, etc., but it should not be the default. > I think adding an option would be totally fine, keep the current default. It can be difficult getting the order right when scripting and adding a few options to the update command could make the scripts quite a bit simpler. If this seems like a reasonable path forward maybe we could sketch out what those options should look like and we might be able to put a patch together. Our most common dashboard use case just wants a pristine clone, using the latest submodule URLs and ideally should clean out any local changes. We seem to spend quite a bit of time ensuring this all happens in the right order, as I think others do. Marcus -- 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
