[cmake-developers] ExternalProject and git clone

[Daniele E. Domenichelli]

On 11/09/13 16:35, David Cole wrote:
>> The EP_ prefix is not needed because this is already an option of
>> the ExternalProject_Add function.  How about SOURCE_DIR_PRESERVE?
>
> To me, the name SOURCE_DIR_PRESERVE implies that the source dir, if
> it exists, will not be touched by the download command or the
> update command at all.
>
> If it will be modified or deleted at all, then there must be a more
> appropriate name than "preserve".

I cannot find a better name, so I used SOURCE_DIR_PRESERVE...
Perhaps SOURCE_DIR_SAFE or something similar?


> In my opinion, a better strategy in this case is to require source
> trees that need preserving or manual interventions to be setup
> manually and simply pointed to with SOURCE_DIR, with empty download
> and update commands.

This makes a lot harder to setup a superbuild, or to add a new module.


> My main point being: if you're actively developing code in these
> source trees, then they're not really "External", are they?

It depends from what you mean with the word "Project". Each researcher
of my group works on different "projects",
so from their point of view, each project is "external" except for the
one they are working on. But perhaps from a "global" point of view they
are all subprojects of a main huge project.



On 11/09/13 16:46, Bill Hoffman wrote:
> If you want to take advantage of ExternalProject, then you have to
> make all your projects external even the main one you are
> developing.  That is just the nature of ExternalProject.  So, for
> most projects at least one of the projects in a "SuperBuild" will
> be the main project they are working on.   Having ExternalProject
> do an initial checkout is a great way to get an initial build for a
> developer.

That's exactly the point, especially since there is not a "main project"
that everyone is developing, the project is composed by a large number
of modules, used by a large heterogeneous group of "lazy" researches
(meaning that it is hard to convince them to learn how to use new
software tools, and training is complicated), interested only in a few
modules, used to SVN (at the moment the project is on a large SVN and
people is used to updating only the subfolders they are actively
developing, or update everything when there is some major update), with
a limited knowledge of git and cmake, and working on different systems
(linux, windows, and macos).

Also some modules and dependencies can be installed on the system, and
therefore should not be downloaded and built, but most of them should be
built to get the latest available commit, other modules are optional and
should be downloaded only if a user explicitly set an option for them,
other are developed by third parties (other research groups scattered
around the world) that are actually external, but not dependencies (the
opposite actually).

Having cmake handle the initial checkout of all the modules, all of
this, instead of using git submodules or a separate tools simplifies a
lot the management of the project, the user won't have to learn a new
tool, and makes it easier to move from SVN since it won't require to
move all the modules at once.




Anyway, attached is an updated version of the patch (still working for
git only and lacking of documentation) fixing the issues reported...
Does it look better now?
I have a weird issue with policy CMP0012 (see the patch), is there a
better way to fix it?




Cheers,
 Daniele




-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ExternalProject-Preserve-source-folder-ourside-the-b.patch
Type: text/x-patch
Size: 8887 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20130912/0bc5d1b9/attachment-0001.bin>