[...]
He's not downloading with CMake, he just told git that in this directory is a 
submodule. The user has then to fetch it himself with one command:

http://git.wiki.kernel.org/index.php/GitSubmoduleTutorial
Sorry ... no git expert at all.... my point was just to hack ExternalProject_add to let specify different download ways, apart from URL, SVN_REPOSITORY and mine BZR_REPOSITORY .... would like to have also GIT_REPOSITORY and HG_REPOSITORY ....
[...]
2) also build your main project wit a ExternalProject_Add and drive the whole thing from 
a "master-CMakeLists.txt"

The first one is probably easier to set up, but requires you to guess the 
installation names and paths correctly. The second option requires you to 
restructure your whole build system and adds considerable complexity due to the 
communication between your master-project and the external projects. For this 
communication I'd try the following:

- In the master project do all the feature-detection and setting of cache 
variables (such as options etc)
- Write a cache-initializer script to the binary tree
- Do all the ExternalProject_Add calls and specify the cache-initializer script 
with the -C option in CMAKE_ARGS
This suggestion is really interesting:    the purpouse is to let any config  options in the 
"master"  projects to be passed to the "slaves"?
Have you any examples?

You could pass every single cache variable using -D in CMAKE_ARGS, but that 
becomes pretty tedious very soon... Currently I don't have any example, sorry.
from http://www.cmake.org/cmake/help/cmake-2-8-docs.html#opt:-Cinitial-cache
seems that what you are suggesting is not passing the master cache to the slaves, but to build a selection of variables and build a script in a different format.... Do you suggesto to pass the same script to ALL the subprojects? I' ll try to find some examples of that usage.....seems useful
I came up with a schema like 2:
any project is built as external, dependencies are resolved by  
ExternalProject_Add and I have used CMAKE_ARGS to communicate settings:
As most of cmake projects were based on FindXXX stuff for finding deps, I have 
overridden the necessary modules in order to make the projects find the good 
components at configure time.

That's what you could do with the cache-initialization script, no need to 
override the FindXXX modules. If more than one of the external projects use the 
same FindXXX module, do it in the master and then communicate the results using 
the initializer script. This way the user can easily override the results 
during the configure-step and get consistent results in all the sub-projects. 
Only thing that has me worried is when the user aborts the build, changes the 
settings in the master cache and then restarts the build. You'd need to somehow 
set up correct dependencies...
If the cache-initialization script is single, then would be good that all the slave projects file_depends on that.... but do not know how to set a file dependency on the configure step of ExternalProject_Add
If sub-project B does a FIND_PACKAGE(A REQUIRED) and A is built as another 
sub-project, then you can specify A_DIR to the B project containing the path to 
the directory containing its A-config.cmake.
Yes, that would be good.... unfortunately not so many cmake projects builds xxx-config.cmake in their build-install process.... It would be nice to have good examples of usages:
this could be a  "standard" way of building dependencies throug cmake .

Is this ExternalProject_Add feature really used/developed? I find it really nice but a little scared of weather it will be really supported and improved. I have done some patching on it but not know if there is a group of user/developer eventually interested to submit mods to

Thanks
             Luigi

_______________________________________________
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

Reply via email to