[CMake] libfoo.dll foo.exe liblib collision problem
Brandon J. Van Every
bvanevery at gmail.com
Mon Dec 12 01:45:26 EST 2005
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
More information about the CMake
mailing list