Jorge Rodriguez wrote:
Brandon J. Van Every wrote:
In any event, the *target* names must be unique. For instance my
actual targets are chicken, libchicken, and libchicken-static. You
use SET_TARGET_PROPERTIES to change what the OUTPUT_NAME name will
be. I've attached the relevant sections of Chicken's CMakeLists.txt,
as they are a fairly clear example of CMake 2.4.3 naming problems and
workarounds on Windows.
I'm not building Cygwin or MinGW. So, I would have to do something
like this?
ADD_LIBRARY(foo SHARED ${FooSources})
ADD_LIBRARY(foos STATIC ${FooSources})
SET_TARGET_PROPERTIES(foos PROPERTIES OUTPUT_NAME foo)
Yep.
Won't that build all the sources twice?
Yes, and that's a perfectly valid thing to do. Chicken, for instance,
has different dllexports and various flags for shared vs. static builds.
That's not really optimal when there's no difference between the
resulting object files. I'd rather it ran the linker twice, once for
shared and once for static, with the same object files. Or maybe
that's me being too optimistic?
Chicken is too small a project for me to have worried about this. I'll
leave discussion on this to others. In principle it's a valid point.
In practice, it would mean isolating .c files that need to be built 2
different ways, from .c files that will get built the same way whether
shared or static. That's complicated.
Also, what if I turned around and did this:
ADD_EXECUTABLE(bar ${BarSources})
TARGET_LINK_LIBRARIES(bar foo)
Would it link against foo or foos?
foo. It goes by the *target* name, which must be unique in CMake. Not
the library name.
Cheers,
Brandon Van Every
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
