[CMake] Building static libraries fails to remove properly

Kevin Ballard ballard at yahoo-inc.com
Wed Mar 8 15:25:31 EST 2006


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".

Thanks,
Kevin Ballard

-- 
Kevin Ballard
Yahoo! Mac Engineer
ballard at yahoo-inc.com
Work: (408) 349-6693
Cell: (408) 660-5028
Yahoo! ID: k_r_ballard




More information about the CMake mailing list