Brandon Van Every wrote:
I thought REMOVE_RECURSE was a straightforward unconditional nuke. I
don't see that cleanliness has anything to do with it.
Well, if I want to clean (remove) a directory, I'd expect it to be
removed regardless if it contains subdirectories.
Regards,
rod
__
Brandon Van Every wrote:
FILE commands are performed at configuration time. They don't have
any relevance to actions performed at build time. Not unless you've
wrapped them up in a CMake script and issued an ADD_CUSTOM_COMMAND of
the form COMMAND ${CMAKE_COMMAND} -P myscript.cmake.
I think y
Brandon Van Every wrote:
Sounds like a bug. File a reproducer in the bug tracker.
Yes, that's what I thought. I've filled bug report #6180 with a patch to
correct this.
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mai
On Dec 18, 2007 1:55 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
>
> > I thought REMOVE_RECURSE was a straightforward unconditional nuke. I
> > don't see that cleanliness has anything to do with it.
>
> Well, if I want to clean (remove) a directory, I'd expect
On Dec 18, 2007 2:33 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
>
> I think you misunderstood what I meant. Then we do 'make clear', the
> CMakeFiles/project.dir/cmake_clean.cmake gets executed. That's where the
> FILE(REMOVE ...) command I'm talking about resides. This is created by
> c