[CMake] Building static libraries fails to remove properly

[William A. Hoffman]

At 03:25 PM 3/8/2006, Kevin Ballard wrote:
>I've been working on getting my cmake build setup building universal  
>binaries on Darwin. I finally got it to a point where it works, only  
>to discover that it only works on a clean build. If I touch any of my  
>source files and re-build it dies when trying to link the static  
>library. The reason is because the cmake-generated build.make file  
>for the static library has incorrect paths when it tries to remove  
>the existing static library, and then the `ar` tool fails because the  
>static library is universal and `ar` can't handle universal  
>libraries. This isn't a problem with thin static libraries because  
>`ar` is perfectly content to swap out the object files in the  
>library, which is why this wasn't discovered before.
>
>Here's the exact setup. the library is placed into dist/Darwin-8.5.0/ lib/Debug/libYMSG_s.a and the source exists in ymsg/source. The  
>build.make file is in ymsg/source/CMakeFiles/YMSG_s.dir. The build  
>rule itself reads:
>
>        @echo "Linking CXX static library ../../dist/Darwin-8.5.0/lib/Debug/ libYMSG_s.a"
>        $(CMAKE_COMMAND) -E remove -f ../../dist/Darwin-8.5.0/lib/Debug/ libYMSG_s.a ../../dist/Darwin-8.5.0/lib/Debug/libYMSG_s.dylib
>        cd /Users/ballard/Dev/perforce/ClientPlatform/Projects/ymsg/source  
>&& /usr/bin/ar cr ../../dist/Darwin-8.5.0/lib/Debug/libYMSG_s.a  $ (YMSG_s_OBJECTS) $(YMSG_s_EXTERNAL_OBJECTS)
>        cd /Users/ballard/Dev/perforce/ClientPlatform/Projects/ymsg/source  
>&& /usr/bin/ranlib ../../dist/Darwin-8.5.0/lib/Debug/libYMSG_s.a
>
>There's 2 things wrong here.
>
>#1) "$(CMAKE_COMMAND) -E remove -f" is unnecessary - $(RM) was  
>already set to that higher up, so that should just be "$(RM) files"
>
>#2) When I poke around, this appears to be executing from the root  
>directory of the project, not the ymsg/source directory. Thus the  
>"../../" prefix on all the paths is wrong. However, the cmake command  
>just silently fails so this went unnoticed until now.
>
>AFAICT nothing in our CMake files has any effect on this build rule,  
>so I'm thinking this has to be a bug in cmake itself. Unfortunately  
>I'm not terribly familiar with cmake, I just build with it. Does  
>anybody have any suggestions/ideas about this?
>
>Oh, and the output of `cmake --version` is "cmake version 2.2-patch 3".

This has been fixed in cvs cmake.

-Bill