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

[Brandon J. Van Every]

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.


Cheers,
Brandon Van Every
RTFM ISA PITA