On Thu, Apr 21, 2011 at 9:44 AM, Michael Wild <them...@gmail.com> wrote: > On 04/21/2011 02:45 PM, David Cole wrote: >> On Thu, Apr 21, 2011 at 4:30 AM, Michael Wild <them...@gmail.com >> <mailto:them...@gmail.com>> wrote: >> >> On 04/21/2011 06:48 AM, Michael Wild wrote: >> > Hi all >> > >> > I'm trying to set up a SuperBuild here. Everything works nicely the >> > first time round I build the project. The only real problem I have is >> > that if I change the sources of one of the sub-projects, the >> SuperBuild >> > still thinks everything is up to date. Of course, this is fully >> > explainable by the fact that the SuperBuild knows nothing about the >> > internal dependencies of the sub-project, and since the stamp >> files are >> > all there and unchanged, it thinks everything is fine. How do I get >> > around this? Anybody got an idea? >> > >> > Thanks >> > >> > Michael >> >> >> Found it myself. For completeness and documentation purposes: Add a >> custom target which removes the *-complete (see ExternalProject.cmake on >> where it is located, it is a bit tricky) and -*configure stamps. Of >> course, it should always run and depend on the external project target. >> >> The thing I'm struggling with now is installing the various sub-projects >> into the system. Seems like it is impossible to install an imported >> target [1], but guessing and hard coding the paths is also not very >> attractive, but probably the only way to go at the moment. If anybody >> has a better idea, please speak up... >> >> If your intent is *always* to run the configure and later steps of an >> ExternalProject build, you can consider adding an extra custom step that >> configure depends on, which does nothing, but ALWAYS runs... No need to >> do any fancy scrounging of stamp files for this to work. >> >> >> Something like: >> >> ExternalProject_Add(Proj1 >> ... >> ) >> >> ExternalProject_Add_Step(Proj1 forceconfigure >> COMMAND ${CMAKE_COMMAND} -E echo "This custom external project step >> forces the configure and later steps to run whenever a top level build >> is done..." >> DEPENDEES download >> DEPENDERS configure >> ALWAYS 1 >> ) > > Mhm, I thought I already tried this, but will check again. Thanks for > the input.
We were messing with stamps in Titan too...just tried this approach and it worked well. I will update Titan and some other projects, as this is a much cleaner solution. > > I also solved my installation problem. By having all sub-projects > install into a common prefix, and thanks to the wonders of RPATH and > install_name which can handle relative paths and thanks to the fact that > install(EXPORT) generated files are also relocatable, I can simply do a > install(DIRECTORY) in the super project ;-) The only thing that required > some thinking was writing a relocatable XXXConfig.cmake file. I think I > will update my tutorial on the WIKI to use a un-configured, relocatable > XXXConfig.cmake file. > I have been using a common prefix in a new superbuild project I have been working on, and I think this is a very clean approach. Coupled with the relocatable Config files it allows you to keep things very simple. 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