cmake: OUTPUT_NAME vs DEBUG_OUTPUT_NAME

Jean's patches modified the cmake building of libraries like this:

ADD_LIBRARY(orocos-rtt-${OROCOS_TARGET}_dynamic SHARED
$ENV{GLOBAL_LIBRARY_SRCS})
SET_TARGET_PROPERTIES( orocos-rtt-${OROCOS_TARGET}_dynamic PROPERTIES
DEFINE_SYMBOL "RTT_DLL_EXPORT"
SOVERSION "${RTT_VERSION_MAJOR}.${RTT_VERSION_MINOR}"
VERSION "${RTT_VERSION}"
OUTPUT_NAME orocos-rtt-${OROCOS_TARGET}
+ DEBUG_OUTPUT_NAME orocos-rtt-${OROCOS_TARGET}d

Is this what we want on Linux ? Aren't debug symbols just a separate file
instead of a differently built library ?

I could replace the 'd' with ${DEBUG_LIB_SUFFIX} or something similar, which
takes a 'd' in win32 and '' on other platforms ?

It breaks some of my cmake macro's too :

get_target_property(PLUGINLIB ${name}-${OROCOS_TARGET}_plugin LOCATION)

if (PROJ_BINARY_DIR)
add_custom_command(TARGET ${name}-${OROCOS_TARGET}_plugin POST_BUILD
COMMAND ${CMAKE_COMMAND} -E make_directory
${PROJ_BINARY_DIR}/rtt/plugins
COMMAND ${CMAKE_COMMAND} -E copy ${PLUGINLIB}
${PROJ_BINARY_DIR}/rtt/plugins)
endif(PROJ_BINARY_DIR)

-> PLUGINLIB always resolves to the 'OUTPUT_NAME' variable and not to the
DEBUG_ variant for debug builds. So it tries to copy a non-existant file to
rtt/plugins...

Peter

cmake: OUTPUT_NAME vs DEBUG_OUTPUT_NAME

Le 02/07/2010 16:21, Peter Soetens a écrit :
> Jean's patches modified the cmake building of libraries like this:
>
> ADD_LIBRARY(orocos-rtt-${OROCOS_TARGET}_dynamic SHARED
> $ENV{GLOBAL_LIBRARY_SRCS})
> SET_TARGET_PROPERTIES( orocos-rtt-${OROCOS_TARGET}_dynamic PROPERTIES
> DEFINE_SYMBOL "RTT_DLL_EXPORT"
> SOVERSION "${RTT_VERSION_MAJOR}.${RTT_VERSION_MINOR}"
> VERSION "${RTT_VERSION}"
> OUTPUT_NAME orocos-rtt-${OROCOS_TARGET}
> + DEBUG_OUTPUT_NAME orocos-rtt-${OROCOS_TARGET}d
>
> Is this what we want on Linux ? Aren't debug symbols just a separate file
> instead of a differently built library ?

On windows platform there are two main differences with the linux/unix
shared libraries:
* The symbols are resolved during compile time (when linking against a
.dll you still need the corresponding .lib or equivalent).
* Binaries are not usually compatible between Debug and Release
(especially with C++, not necessarily for C) because of different libstd
ABI's (there is 4 libstd and libc sets on windows).

Because of that, one fear (among others) of the windows developer is the
Debug/Release DLL hell (and mixing the two leads to another circle of
hell full of .manifest). So to avoid any nasty problems (from linking
problems to "strange" runtime bugs), we prefer to distinguish clearly
between debug and release builds.

> I could replace the 'd' with ${DEBUG_LIB_SUFFIX} or something
similar, which
> takes a 'd' in win32 and '' on other platforms ?

I think this would be the best cross-platform solution.

cmake: OUTPUT_NAME vs DEBUG_OUTPUT_NAME

On Friday 09 July 2010 14:13:48 Jean Sreng wrote:
> Le 02/07/2010 16:21, Peter Soetens a écrit :
> > Jean's patches modified the cmake building of libraries like this:
> >
> > ADD_LIBRARY(orocos-rtt-${OROCOS_TARGET}_dynamic SHARED
> > $ENV{GLOBAL_LIBRARY_SRCS})
> > SET_TARGET_PROPERTIES( orocos-rtt-${OROCOS_TARGET}_dynamic PROPERTIES
> > DEFINE_SYMBOL "RTT_DLL_EXPORT"
> > SOVERSION "${RTT_VERSION_MAJOR}.${RTT_VERSION_MINOR}"
> > VERSION "${RTT_VERSION}"
> > OUTPUT_NAME orocos-rtt-${OROCOS_TARGET}
> > + DEBUG_OUTPUT_NAME orocos-rtt-${OROCOS_TARGET}d
> >
> > Is this what we want on Linux ? Aren't debug symbols just a separate
> > file instead of a differently built library ?
>
> On windows platform there are two main differences with the linux/unix
> shared libraries:
> * The symbols are resolved during compile time (when linking against a
> .dll you still need the corresponding .lib or equivalent).
> * Binaries are not usually compatible between Debug and Release
> (especially with C++, not necessarily for C) because of different libstd
> ABI's (there is 4 libstd and libc sets on windows).
>
> Because of that, one fear (among others) of the windows developer is the
> Debug/Release DLL hell (and mixing the two leads to another circle of
> hell full of .manifest). So to avoid any nasty problems (from linking
> problems to "strange" runtime bugs), we prefer to distinguish clearly
> between debug and release builds.
>
> > I could replace the 'd' with ${DEBUG_LIB_SUFFIX} or something
>
> similar, which
>
> > takes a 'd' in win32 and '' on other platforms ?
>
> I think this would be the best cross-platform solution.

I have added this for the RTT (CMAKE_DEBUG_LIB_SUFFIX). OCL is still lacking
this I suppose.

Peter

cmake: OUTPUT_NAME vs DEBUG_OUTPUT_NAME

On Mon, Jul 12, 2010 at 4:49 PM, Peter Soetens <peter [..] ...>wrote:

> On Friday 09 July 2010 14:13:48 Jean Sreng wrote:
> > Le 02/07/2010 16:21, Peter Soetens a écrit :
> > > Jean's patches modified the cmake building of libraries like this:
> > >
> > > ADD_LIBRARY(orocos-rtt-${OROCOS_TARGET}_dynamic SHARED
> > > $ENV{GLOBAL_LIBRARY_SRCS})
> > > SET_TARGET_PROPERTIES( orocos-rtt-${OROCOS_TARGET}_dynamic
> PROPERTIES
> > > DEFINE_SYMBOL "RTT_DLL_EXPORT"
> > > SOVERSION "${RTT_VERSION_MAJOR}.${RTT_VERSION_MINOR}"
> > > VERSION "${RTT_VERSION}"
> > > OUTPUT_NAME orocos-rtt-${OROCOS_TARGET}
> > > + DEBUG_OUTPUT_NAME orocos-rtt-${OROCOS_TARGET}d
> > >
> > > Is this what we want on Linux ? Aren't debug symbols just a separate
> > > file instead of a differently built library ?
> >
> > On windows platform there are two main differences with the linux/unix
> > shared libraries:
> > * The symbols are resolved during compile time (when linking against a
> > .dll you still need the corresponding .lib or equivalent).
> > * Binaries are not usually compatible between Debug and Release
> > (especially with C++, not necessarily for C) because of different libstd
> > ABI's (there is 4 libstd and libc sets on windows).
> >
> > Because of that, one fear (among others) of the windows developer is the
> > Debug/Release DLL hell (and mixing the two leads to another circle of
> > hell full of .manifest). So to avoid any nasty problems (from linking
> > problems to "strange" runtime bugs), we prefer to distinguish clearly
> > between debug and release builds.
> >
> > > I could replace the 'd' with ${DEBUG_LIB_SUFFIX} or something
> >
> > similar, which
> >
> > > takes a 'd' in win32 and '' on other platforms ?
> >
> > I think this would be the best cross-platform solution.
>
> I have added this for the RTT (CMAKE_DEBUG_LIB_SUFFIX). OCL is still
> lacking
> this I suppose.
>

Is CMAKE_DEBUG_LIB_SUFFIX a custom variable?. I looked at the cmake doc and
did not find any references to it. What I did find was
CMAKE_<CONFIG>_POSTFIX [1] (with <config>=DEBUG in this case) which seems to
do what you want.

[1]
http://cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_CONFIG_PO...

Adolfo

>
> Peter
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

cmake: OUTPUT_NAME vs DEBUG_OUTPUT_NAME

On Monday 12 July 2010 17:14:47 Adolfo Rodríguez Tsouroukdissian wrote:
> On Mon, Jul 12, 2010 at 4:49 PM, Peter Soetens
<peter [..] ...>wrote:
> > On Friday 09 July 2010 14:13:48 Jean Sreng wrote:
> > > Le 02/07/2010 16:21, Peter Soetens a écrit :
> > > > Jean's patches modified the cmake building of libraries like this:
> > > >
> > > > ADD_LIBRARY(orocos-rtt-${OROCOS_TARGET}_dynamic SHARED
> > > > $ENV{GLOBAL_LIBRARY_SRCS})
> > > > SET_TARGET_PROPERTIES( orocos-rtt-${OROCOS_TARGET}_dynamic
> >
> > PROPERTIES
> >
> > > > DEFINE_SYMBOL "RTT_DLL_EXPORT"
> > > > SOVERSION "${RTT_VERSION_MAJOR}.${RTT_VERSION_MINOR}"
> > > > VERSION "${RTT_VERSION}"
> > > > OUTPUT_NAME orocos-rtt-${OROCOS_TARGET}
> > > > + DEBUG_OUTPUT_NAME orocos-rtt-${OROCOS_TARGET}d
> > > >
> > > > Is this what we want on Linux ? Aren't debug symbols just a separate
> > > > file instead of a differently built library ?
> > >
> > > On windows platform there are two main differences with the linux/unix
> > > shared libraries:
> > > * The symbols are resolved during compile time (when linking against
> > > a .dll you still need the corresponding .lib or equivalent).
> > > * Binaries are not usually compatible between Debug and Release
> > > (especially with C++, not necessarily for C) because of different
> > > libstd ABI's (there is 4 libstd and libc sets on windows).
> > >
> > > Because of that, one fear (among others) of the windows developer is
> > > the Debug/Release DLL hell (and mixing the two leads to another circle
> > > of hell full of .manifest). So to avoid any nasty problems (from
> > > linking problems to "strange" runtime bugs), we prefer to distinguish
> > > clearly between debug and release builds.
> > >
> > > > I could replace the 'd' with ${DEBUG_LIB_SUFFIX} or something
> > >
> > > similar, which
> > >
> > > > takes a 'd' in win32 and '' on other platforms ?
> > >
> > > I think this would be the best cross-platform solution.
> >
> > I have added this for the RTT (CMAKE_DEBUG_LIB_SUFFIX). OCL is still
> > lacking
> > this I suppose.
>
> Is CMAKE_DEBUG_LIB_SUFFIX a custom variable?. I looked at the cmake doc and
> did not find any references to it. What I did find was
> CMAKE_<CONFIG>_POSTFIX [1] (with <config>=DEBUG in this case) which seems
> to do what you want.
>
> [1]
> http://cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_CONFIG_POSTF
> IX

You are right. We need to set this variable instead of the home made version.

Peter

cmake: OUTPUT_NAME vs DEBUG_OUTPUT_NAME

On Jul 2, 2010, at 10:21 , Peter Soetens wrote:

> Jean's patches modified the cmake building of libraries like this:
>
> ADD_LIBRARY(orocos-rtt-${OROCOS_TARGET}_dynamic SHARED
> $ENV{GLOBAL_LIBRARY_SRCS})
> SET_TARGET_PROPERTIES( orocos-rtt-${OROCOS_TARGET}_dynamic PROPERTIES
> DEFINE_SYMBOL "RTT_DLL_EXPORT"
> SOVERSION "${RTT_VERSION_MAJOR}.${RTT_VERSION_MINOR}"
> VERSION "${RTT_VERSION}"
> OUTPUT_NAME orocos-rtt-${OROCOS_TARGET}
> + DEBUG_OUTPUT_NAME orocos-rtt-${OROCOS_TARGET}d
>
> Is this what we want on Linux ? Aren't debug symbols just a separate file
> instead of a differently built library ?

Linux = separate library in most distro's.

Mac OS X = not really sure that there is a standard here.

It sounds like it will definitely introduce trouble for us, but I'm curious as to Jean's intent with this patch?
S