[CMake] libfoo.dll foo.exe liblib collision problem

[William A. Hoffman]

At 01:45 AM 12/12/2005, Brandon J. Van Every wrote:
>In the Windows world, it is considered reasonable to name related pieces of software thus:
>
>libfoo.dll - a dynamic link library
>foo.exe - an app that uses the libfoo.dll
>
>The problem is, when trying to make this cross-platform, Unixn like to tack lib* onto the front of anything that's going to be a lib.  So if you do
>
>ADD_LIBRARY(libfoo ${LIBFOO_SOURCES})
>
>what you'll get in a Linux, Cygwin, or MinGW environment is liblibfoo.dll.  Which is wrong, and breaks builds.  So, let's say you've read the CMake archives and gone for the "it's not a bug, it's a feature!" response to someone's proferred Linux liblib patch.  Ok, great.  You do
>
>ADD_LIBRARY(foo ${LIBFOO_SOURCES})
>ADD_EXECUTABLE(foo_exe ${FOO_EXE_SOURCES})
>SET_TARGET_PROPERTIES(foo_exe PROPERTIES OUTPUT_NAME foo)
>[...]
>TARGET_LINK_LIBRARIES(bar foo)
>
>And now CMake will say something intelligent like:
>make[2]: *** No rule to make target `foo.exe', needed by `bar.c'.  Stop.
>
>So, if you try to solve it "on the lib* side," you get killed.  If you try to solve it "on the .exe side," you get killed.  You're damned if you do, damned if you don't.  And let's say, for sake of argument and reality, that you're dealing with legacy systems or managerial policies that do *not* entitle you to rename the app or the library.
>
>Is there a canonical dance to resolve this?  I hope so.  If not, there should be.

The way I fixed it was to make the name of the library a variable.

SET(FOO_LIB foo)
IF(WIN32 AND NOT CYGWIN)
   SET(FOO_LIB_NAME libfoo)
ENDIF(WIN32_AND_NOT_CYGWIN)
ADD_LIBRARY(${FOO_LIB_NAME} ${LIBFOO_SOURCES})

However, changing the output name should work and is really just a bug in CMake.
Please make a bug report www.cmake.org/Bug.

-Bill