[CMake] ExternalProject() Question

Michael Wild themiwi at gmail.com
Thu Dec 17 11:41:09 EST 2009


On 17. Dec, 2009, at 17:34 , David Cole wrote:

> On Thu, Dec 17, 2009 at 10:53 AM, Michael Wild <themiwi at gmail.com> wrote:
> 
>> 
>> On 17. Dec, 2009, at 15:01 , David Cole wrote:
>> 
>>> On Thu, Dec 17, 2009 at 3:20 AM, Michael Wild <themiwi at gmail.com> wrote:
>>> 
>>>> 
>>>> On 16. Dec, 2009, at 20:35 , Michael Jackson wrote:
>>>> 
>>>>> I am intrigued by the "ExternalProject" feature of CMake 2.8. One
>>>> question that I have after reading through the Oct 09 "Kitware Source"
>> is
>>>> this. If I do a "make clean" or "rebuild" are all the "ExternalProjects"
>>>> also cleaned/rebuilt? I could make an argument both ways but I was
>> curious
>>>> what the default was?
>>>>> 
>>>>> One of my projects depends on HDF5, Tiff, Expat and Boost (And Qt
>>>> Eventually). Writing directions to get everything downloaded and built
>> is
>>>> getting to be a pain. Would be simpler to have all that done for the
>> user.
>>>>> 
>>>>> Thanks for any comments
>>>>> _________________________________________________________
>>>>> Mike Jackson                  mike.jackson at bluequartz.net
>>>>> BlueQuartz Software                    www.bluequartz.net
>>>>> Principal Software Engineer                  Dayton, Ohio
>>>>> 
>>>> 
>>>> "make clean" behaves a bit strange for me... It seems to remove some of
>> the
>>>> stamp files, but does not actually perform a "clean" on the external
>>>> project, or wipe the extracted sources. For me, this is a bit of a
>> problem,
>>>> since the PATCH_COMMAND will try to re-apply a patch, which of course
>> will
>>>> fail. Not sure how to teach CMake to not re-patch a source tree...
>> Perhaps
>>>> wrap the whole thing in a apply_patch.cmake script which creates its own
>>>> stamp in the external source tree and only applies the patch if that
>> stamp
>>>> does not exist...
>>>> 
>>>> 
>>> Michael Wild's observations are correct. The "make clean" of the outer
>>> project is going to wipe all the stamp files causing all of the steps to
>>> re-run again, including downloads and checkouts.
>>> 
>>> Since the patch command is empty by default and 'patch' is not readily
>>> available on Windows, the patching stuff is less well tested than the
>> rest
>>> of the steps.
>>> 
>>> I guess I would be inclined to say that an outer/main-project "make
>> clean"
>>> ought to default to cleaning the inner/nested/external projects as
>> well...
>>> but it's not clear to me that there's a reasonable way to implement that
>>> quickly and easily. It's certainly worthy of a feature request and some
>>> discussion. And whatever the default behavior is, it should probably be
>>> controllable by one or more new arguments to the ExternalProject_Add
>>> function.
>>> 
>>> Let me know if you have further ideas and suggestions.
>>> 
>>> 
>>> Thanks,
>>> David Cole
>> 
>> 
>> Also, should a "make clean" really trigger a re-download? What I would like
>> to have is a MD5SUM option to ExternalProject_Add. Currently I'm
>> implementing this manually with a custom sub-step, but there's no reason it
>> shouldn't be in CMake, because it natively implements -E md5sum.
> 
> 
> 
> The MD5SUM option is a good idea that we have considered. I'm almost certain
> md5 (or something like it) will appear in a future implementation of
> ExternalProject_Add.
> 
> Ideally, I think "make clean" should destroy all created build products. And
> in the case of ExternalProject_Add, the downloaded source is a "build
> product." I understand why you would not want to re-download the source...
> You could put a *.tar.gz in your source tree and reference it directly
> there. You might not want to do that, either, though.
> 
> Thanks for the discussion.

Currently I'm checking whether it is in the source tree and the MD5 matches, and otherwise I download it.

Speaking of the MD5 sum, it would be nice if it would be possible to do something like this:

if(${filename} MD5SUM_EQUAL ${md5sum})


in the CMake code, because using execute_process every time and then parsing the output is a bit tedious.

Michael


More information about the CMake mailing list