On 6 July 2011 17:27, David Cole <david.c...@kitware.com> wrote:
> (Don't know if you meant to omit the CMake mailing list on that, or if that
> was on oversight.... Feel free to put my responses back on list if you
> wish.)
Oops, no I didn't mean to omit the mailing list.
One more point: ExternalProject is completely and fully customizable. You
> could certainly add a "clean" step to any ExternalProject that you like. Or
> you could define a "clean_externals" at the top level that goes and cleans
> everything. If you can figure out the right clean sub-commands.....
>
I'm not sure but wouldn't getting clean to work with Visual Studio require
changes to the generator code to add hooks in the vcproj files on either the
BeforeClean or AfterClean events ? As far as I can tell Visual Studio cleans
a project by deleting the files it thinks the project creates. For normal
C/C++ projects this works as expected but for external projects the created
files are not known in the external project vcproj file. However, they are
known in the subdirectory external project vcproj file. To clarify, in my
case the external project has these 2 vcproj files:
<buildDir>/external_proj.vcproj
<buildDir>/external_proj/src/external_proj-build/myProjName.vcproj
The top level external_proj.vcproj file only contains a folder of
CMakeBuildRules which specify custom build commands for each of the
configure, build, install etc. steps. When this top level project is built
it invokes cmake --build <buildDir>/external_proj/src/external_proj-build to
do the actual build.
If I clean external_proj then it has no idea what to delete under the
<buildDir>/external_proj/src/external_proj-build directory. But if cmake
had hooked the AfterClean event on external_proj and then called cmake
--build <buildDir>/external_proj/src/external_proj-build --target clean then
that would get Visual Studio to clean the lower level myProjName.vcproj
which does know which files to clean because it is a normal C/C++ project.
The top level external_proj is the only one visible in Visual Studio. The
lower level myProjName is not visble in Visual Studio but it is the only one
that knows how to do the clean. If the top level one forwarded the clean to
it then everything would work.
I haven't checked but I suspect the same thing would work for the Makefile
generators. The top level "make clean" would just call "make clean" on the
lower level makefile.
--
Glenn
On Wed, Jul 6, 2011 at 12:24 PM, David Cole <david.c...@kitware.com> wrote:
>
>> On Wed, Jul 6, 2011 at 12:17 PM, Glenn Coombs <glenn.coo...@gmail.com>wrote:
>>
>>> On 5 July 2011 17:13, David Cole <david.c...@kitware.com> wrote:
>>>
>>>> It is (intentionally) missing some functionality. You have not
>>>> misunderstood.
>>>>
>>>> The general case of ExternalProject is completely arbitrary, although we
>>>> do use reasonable default commands for cmake projects and configure/make
>>>> projects as they are conventionally used... Since it's completely
>>>> arbitrary,
>>>> we do not know if there is a 'clean' target at each level.
>>>>
>>>
>>> Don't all projects configured using cmake have a clean target ?
>>> Certainly the makfiles on linux have a clean target, and the Visual Studio
>>> projects can all be individually cleaned. It looks like
>>> ExternalProject_Add() already adds special case targets for test and install
>>> so that they end up calling:
>>>
>>> cmake --build ${buildDir} --config ${CMAKE_CFG)INTDIR} --target test
>>> cmake --build ${buildDir} --config ${CMAKE_CFG)INTDIR} --target
>>> install
>>>
>>> Would it not make sense to also add a special target for clean in the
>>> same manner ?
>>>
>>
>> It would make sense. But there is no "--target clean" on Visual Studio
>> builds. Visual Studio has a clean mechanism, not a clean build target. So
>> the API for doing a clean operation is inconsistent across all CMake
>> generators. If it were consistent, I might be inclined to agree with you,
>> but it's not.
>>
>>
>>
>>
>>>
>>>
>>>> The best 'clean' is starting with an absolutely empty build tree, and
>>>> running CMake and your build system from there.
>>>>
>>>> Since the best 'clean' is always going to be better than any
>>>> target-based clean we could come up with, I wouldn't even attempt to add
>>>> this functionality unless nearly everybody unanimously agreed that we
>>>> should
>>>> have it. And only then if somebody writes a patch to provide it.
>>>>
>>>
>>> On those grounds why do the cmake generated makefiles provide a clean
>>> target ?
>>>
>>
>> Because it was already here when I got here. :-) I'm pretty sure the
>> primary motivation is because some projects have ridiculously long initial
>> configuration times, and avoiding that by keeping the cache while blowing
>> away the object files is useful to some... Personally, I'd rather see folks
>> work on minimizing their configure times.
>>
>>
>>
>>>
>>> Given that the infrastructure for cleaning is already present in cmake
>>> configured projects what reason is there to deliberately omit the code to
>>> call that funcionality ?
>>>
>>
>> As mentioned above, there is no consistent API that is convenient for
>> calling from the ExternalProject code available. If it were available, I'd
>> say we could do it. As it stands, I think it's better left to full clean and
>> rebuild by the end users.
>>
>>
>>
>>>
>>> --
>>> Glenn
>>>
>>>
>>
>> Thanks,
>> David
>>
>>
>
_______________________________________________
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
