Many oroblems while mixing build configurations on win32

Submitted by phamelin on Wed, 2011-05-25 16:44

RTT-dev

Hello,

there's some problems when using multiple configurations (e.g., debug and
release) of RTT and OCL on win32 on the same install path.

*** PROBLEM 1: OCL executables names

Actually, when building RTT and OCL in debug on win32, the postfix "d" is
added to library names. However, this isn't the case for executables. So, in
the case both debug and release binaries are installed, debug or release
executables are just overwrited.

*** PROBLEM 2: OCL linking problem

When both configurations of RTT (debug/release) are build and installed in
the same directory, the OCL FindRTTPlugin link with both libraries if they
are found. The problem is clearer when looking at this snippet of
FindRTTPlugin.cmake :

    if ( RTT_PLUGIN_${COMPONENT}D_LIBRARY )
      list(APPEND RTT_PLUGIN_${COMPONENT}_PROCESS_LIBS
RTT_PLUGIN_${COMPONENT}D_LIBRARY)
    endif()
    if ( RTT_PLUGIN_${COMPONENT}_LIBRARY )
      list(APPEND RTT_PLUGIN_${COMPONENT}_PROCESS_LIBS
RTT_PLUGIN_${COMPONENT}_LIBRARY)
    endif()

*** PROBLEM 3: RTT try to load both debug and release libraries

If both debug and release components are installed in the
RTT_COMPONENT_PATH, RTT tries to load both and this lead to a C++ exception.

No ones of these problems appear if we use a single configuration or if we
install the configurations in different paths. In my opinion, this is not an
option since we want to be able to "Find(Orocos)" and then use the drop box
in Visual Studio to select which configuration to build. If they are
installed on different directories then this will be a big headache to
maintain the CMake logic.

Here is my proposition (only apply to win32 target):

- Modify the FindRTTPlugin to use "debug" and "optimized" keywords in order
to link only with one configuration and not both
- Add the postfix "d" to the executables, so they can both live in the same
binary installation folder
- Add a filter in the plugins/typekit/components loader to only load the
appropriate DLLs, i.e. :

deployer-win32 only loads *win32.dll
deployer-win32d only loads *win32d.dll

- In the same way as RTT, add the postfix "win32" to OCL targets (I don't
know why this is actually done on gnulinux and not on win32?)

Before submitting any patches, I would appreciate to have comments from
Peter and maybe some Windows users.

Philippe

Many oroblems while mixing build configurations on win32

Submitted by peter on Thu, 2011-05-26 10:48.

On Wednesday 25 May 2011 18:43:47 Philippe Hamelin wrote:
> Hello,
>
> there's some problems when using multiple configurations (e.g., debug and
> release) of RTT and OCL on win32 on the same install path.
>
>
> *** PROBLEM 1: OCL executables names
>
> Actually, when building RTT and OCL in debug on win32, the postfix "d" is
> added to library names. However, this isn't the case for executables. So,
> in the case both debug and release binaries are installed, debug or
> release executables are just overwrited.
>
>
> *** PROBLEM 2: OCL linking problem
>
> When both configurations of RTT (debug/release) are build and installed in
> the same directory, the OCL FindRTTPlugin link with both libraries if they
> are found. The problem is clearer when looking at this snippet of
> FindRTTPlugin.cmake :
>
>

> 
>     if ( RTT_PLUGIN_${COMPONENT}D_LIBRARY )
>       list(APPEND RTT_PLUGIN_${COMPONENT}_PROCESS_LIBS
> RTT_PLUGIN_${COMPONENT}D_LIBRARY)
>     endif()
>     if ( RTT_PLUGIN_${COMPONENT}_LIBRARY )
>       list(APPEND RTT_PLUGIN_${COMPONENT}_PROCESS_LIBS
> RTT_PLUGIN_${COMPONENT}_LIBRARY)
>     endif()
> 
>

>
>
> *** PROBLEM 3: RTT try to load both debug and release libraries
>
> If both debug and release components are installed in the
> RTT_COMPONENT_PATH, RTT tries to load both and this lead to a C++
> exception.
>
>
>
> No ones of these problems appear if we use a single configuration or if we
> install the configurations in different paths. In my opinion, this is not
> an option since we want to be able to "Find(Orocos)" and then use the drop
> box in Visual Studio to select which configuration to build. If they are
> installed on different directories then this will be a big headache to
> maintain the CMake logic.
>
> Here is my proposition (only apply to win32 target):
>
> - Modify the FindRTTPlugin to use "debug" and "optimized" keywords in order
> to link only with one configuration and not both

ok.

> - Add the postfix "d" to the executables, so they can both live in the same
> binary installation folder

ok.

> - Add a filter in the plugins/typekit/components loader to only load the
> appropriate DLLs, i.e. :
>
> deployer-win32 only loads *win32.dll
> deployer-win32d only loads *win32d.dll

ok. I didn't dare to implement this, since we had some issues at finding
libraries in the beginning. But if all dlls end in the win32.dll or win32d.dll
suffix, there should be no problem in locating the right libraries.

>
> - In the same way as RTT, add the postfix "win32" to OCL targets (I don't
> know why this is actually done on gnulinux and not on win32?)

Hmm. This is because of the UseOrocos.cmake macros. That would be a bug
then...

>
>
> Before submitting any patches, I would appreciate to have comments from
> Peter and maybe some Windows users.

I can certainly help with cross-checking your patches.

Peter

Many oroblems while mixing build configurations on win32

Submitted by phamelin on Fri, 2011-05-27 19:56.

2011/5/26 Peter Soetens <peter [..] ...>

> On Wednesday 25 May 2011 18:43:47 Philippe Hamelin wrote:
> > Hello,
> >
> > there's some problems when using multiple configurations (e.g., debug and
> > release) of RTT and OCL on win32 on the same install path.
> >
> >
> > *** PROBLEM 1: OCL executables names
> >
> > Actually, when building RTT and OCL in debug on win32, the postfix "d" is
> > added to library names. However, this isn't the case for executables. So,
> > in the case both debug and release binaries are installed, debug or
> > release executables are just overwrited.
> >
> >
> > *** PROBLEM 2: OCL linking problem
> >
> > When both configurations of RTT (debug/release) are build and installed
> in
> > the same directory, the OCL FindRTTPlugin link with both libraries if
> they
> > are found. The problem is clearer when looking at this snippet of
> > FindRTTPlugin.cmake :
> >
> >

> >
> >     if ( RTT_PLUGIN_${COMPONENT}D_LIBRARY )
> >       list(APPEND RTT_PLUGIN_${COMPONENT}_PROCESS_LIBS
> > RTT_PLUGIN_${COMPONENT}D_LIBRARY)
> >     endif()
> >     if ( RTT_PLUGIN_${COMPONENT}_LIBRARY )
> >       list(APPEND RTT_PLUGIN_${COMPONENT}_PROCESS_LIBS
> > RTT_PLUGIN_${COMPONENT}_LIBRARY)
> >     endif()
> >
> >

> >
> >
> > *** PROBLEM 3: RTT try to load both debug and release libraries
> >
> > If both debug and release components are installed in the
> > RTT_COMPONENT_PATH, RTT tries to load both and this lead to a C++
> > exception.
> >
> >
> >
> > No ones of these problems appear if we use a single configuration or if
> we
> > install the configurations in different paths. In my opinion, this is not
> > an option since we want to be able to "Find(Orocos)" and then use the
> drop
> > box in Visual Studio to select which configuration to build. If they are
> > installed on different directories then this will be a big headache to
> > maintain the CMake logic.
> >
> > Here is my proposition (only apply to win32 target):
> >
> > - Modify the FindRTTPlugin to use "debug" and "optimized" keywords in
> order
> > to link only with one configuration and not both
>
> ok.
>
> > - Add the postfix "d" to the executables, so they can both live in the
> same
> > binary installation folder
>
> ok.
>
> > - Add a filter in the plugins/typekit/components loader to only load the
> > appropriate DLLs, i.e. :
> >
> > deployer-win32 only loads *win32.dll
> > deployer-win32d only loads *win32d.dll
>
> ok. I didn't dare to implement this, since we had some issues at finding
> libraries in the beginning. But if all dlls end in the win32.dll or
> win32d.dll
> suffix, there should be no problem in locating the right libraries.
>
> >
> > - In the same way as RTT, add the postfix "win32" to OCL targets (I don't
> > know why this is actually done on gnulinux and not on win32?)
>
> Hmm. This is because of the UseOrocos.cmake macros. That would be a bug
> then...
>
> >
> >
> > Before submitting any patches, I would appreciate to have comments from
> > Peter and maybe some Windows users.
>
> I can certainly help with cross-checking your patches.
>
>
Here the first set of patches for RTT to solve all these problemes. The ones
for OCL will follow in the next email. They have been generated from the
v2.3.1 tag. I hope this won't give you much problems.

Philippe

Many oroblems while mixing build configurations on win32

Submitted by phamelin on Fri, 2011-05-27 20:00.

2011/5/27 Philippe Hamelin <philippe [dot] hamelin [..] ...>

> 2011/5/26 Peter Soetens <peter [..] ...>
>
>> On Wednesday 25 May 2011 18:43:47 Philippe Hamelin wrote:
>> > Hello,
>> >
>> > there's some problems when using multiple configurations (e.g., debug
>> and
>> > release) of RTT and OCL on win32 on the same install path.
>> >
>> >
>> > *** PROBLEM 1: OCL executables names
>> >
>> > Actually, when building RTT and OCL in debug on win32, the postfix "d"
>> is
>> > added to library names. However, this isn't the case for executables.
>> So,
>> > in the case both debug and release binaries are installed, debug or
>> > release executables are just overwrited.
>> >
>> >
>> > *** PROBLEM 2: OCL linking problem
>> >
>> > When both configurations of RTT (debug/release) are build and installed
>> in
>> > the same directory, the OCL FindRTTPlugin link with both libraries if
>> they
>> > are found. The problem is clearer when looking at this snippet of
>> > FindRTTPlugin.cmake :
>> >
>> >

>> >
>> >     if ( RTT_PLUGIN_${COMPONENT}D_LIBRARY )
>> >       list(APPEND RTT_PLUGIN_${COMPONENT}_PROCESS_LIBS
>> > RTT_PLUGIN_${COMPONENT}D_LIBRARY)
>> >     endif()
>> >     if ( RTT_PLUGIN_${COMPONENT}_LIBRARY )
>> >       list(APPEND RTT_PLUGIN_${COMPONENT}_PROCESS_LIBS
>> > RTT_PLUGIN_${COMPONENT}_LIBRARY)
>> >     endif()
>> >
>> >

>> >
>> >
>> > *** PROBLEM 3: RTT try to load both debug and release libraries
>> >
>> > If both debug and release components are installed in the
>> > RTT_COMPONENT_PATH, RTT tries to load both and this lead to a C++
>> > exception.
>> >
>> >
>> >
>> > No ones of these problems appear if we use a single configuration or if
>> we
>> > install the configurations in different paths. In my opinion, this is
>> not
>> > an option since we want to be able to "Find(Orocos)" and then use the
>> drop
>> > box in Visual Studio to select which configuration to build. If they are
>> > installed on different directories then this will be a big headache to
>> > maintain the CMake logic.
>> >
>> > Here is my proposition (only apply to win32 target):
>> >
>> > - Modify the FindRTTPlugin to use "debug" and "optimized" keywords in
>> order
>> > to link only with one configuration and not both
>>
>> ok.
>>
>> > - Add the postfix "d" to the executables, so they can both live in the
>> same
>> > binary installation folder
>>
>> ok.
>>
>> > - Add a filter in the plugins/typekit/components loader to only load the
>> > appropriate DLLs, i.e. :
>> >
>> > deployer-win32 only loads *win32.dll
>> > deployer-win32d only loads *win32d.dll
>>
>> ok. I didn't dare to implement this, since we had some issues at finding
>> libraries in the beginning. But if all dlls end in the win32.dll or
>> win32d.dll
>> suffix, there should be no problem in locating the right libraries.
>>
>> >
>> > - In the same way as RTT, add the postfix "win32" to OCL targets (I
>> don't
>> > know why this is actually done on gnulinux and not on win32?)
>>
>> Hmm. This is because of the UseOrocos.cmake macros. That would be a bug
>> then...
>>
>> >
>> >
>> > Before submitting any patches, I would appreciate to have comments from
>> > Peter and maybe some Windows users.
>>
>> I can certainly help with cross-checking your patches.
>>
>>
> Here the first set of patches for RTT to solve all these problemes. The
> ones for OCL will follow in the next email. They have been generated from
> the v2.3.1 tag. I hope this won't give you much problems.
>
> Philippe
>
>
Here is the second set of patches and these ones are for OCL. Again, they
have been generated from the v2.3.1 tag. I hope this won't give you much
problems. I have also fixed a linking problem with readline for windows.
There's a problem with pre-compiled binaries of readline (coming from the
Wiki), because the debug version of readline is linking with both debug and
release CRT. Just downloading the sources and re-compiling both of them
solve the problem.

Philippe

Many oroblems while mixing build configurations on win32

Submitted by peter on Mon, 2011-05-30 22:16.

On Fri, May 27, 2011 at 9:58 PM, Philippe Hamelin
<philippe [dot] hamelin [..] ...> wrote:
> 2011/5/27 Philippe Hamelin <philippe [dot] hamelin [..] ...>
>>
>> 2011/5/26 Peter Soetens <peter [..] ...>
>>>
>>> On Wednesday 25 May 2011 18:43:47 Philippe Hamelin wrote:
>>> > Hello,
>>> >
>>> > there's some problems when using multiple configurations (e.g., debug
>>> > and
>>> > release) of RTT and OCL on win32 on the same install path.
>>> >
>>> >
>>> > *** PROBLEM 1: OCL executables names
>>> >
>>> > Actually, when building RTT and OCL in debug on win32, the postfix "d"
>>> > is
>>> > added to library names. However, this isn't the case for executables.
>>> > So,
>>> > in the case both debug and release binaries are installed, debug or
>>> > release executables are just overwrited.
>>> >
>>> >
>>> > *** PROBLEM 2: OCL linking problem
>>> >
>>> > When both configurations of RTT (debug/release) are build and installed
>>> > in
>>> > the same directory, the OCL FindRTTPlugin link with both libraries if
>>> > they
>>> > are found. The problem is clearer when looking at this snippet of
>>> > FindRTTPlugin.cmake :
>>> >
>>> >

>>> >
>>> >     if ( RTT_PLUGIN_${COMPONENT}D_LIBRARY )
>>> >       list(APPEND RTT_PLUGIN_${COMPONENT}_PROCESS_LIBS
>>> > RTT_PLUGIN_${COMPONENT}D_LIBRARY)
>>> >     endif()
>>> >     if ( RTT_PLUGIN_${COMPONENT}_LIBRARY )
>>> >       list(APPEND RTT_PLUGIN_${COMPONENT}_PROCESS_LIBS
>>> > RTT_PLUGIN_${COMPONENT}_LIBRARY)
>>> >     endif()
>>> >
>>> >

>>> >
>>> >
>>> > *** PROBLEM 3: RTT try to load both debug and release libraries
>>> >
>>> > If both debug and release components are installed in the
>>> > RTT_COMPONENT_PATH, RTT tries to load both and this lead to a C++
>>> > exception.
>>> >
>>> >
>>> >
>>> > No ones of these problems appear if we use a single configuration or if
>>> > we
>>> > install the configurations in different paths. In my opinion, this is
>>> > not
>>> > an option since we want to be able to "Find(Orocos)" and then use the
>>> > drop
>>> > box in Visual Studio to select which configuration to build. If they
>>> > are
>>> > installed on different directories then this will be a big headache to
>>> > maintain the CMake logic.
>>> >
>>> > Here is my proposition (only apply to win32 target):
>>> >
>>> > - Modify the FindRTTPlugin to use "debug" and "optimized" keywords in
>>> > order
>>> > to link only with one configuration and not both
>>>
>>> ok.
>>>
>>> > - Add the postfix "d" to the executables, so they can both live in the
>>> > same
>>> > binary installation folder
>>>
>>> ok.
>>>
>>> > - Add a filter in the plugins/typekit/components loader to only load
>>> > the
>>> > appropriate DLLs, i.e. :
>>> >
>>> > deployer-win32 only loads *win32.dll
>>> > deployer-win32d only loads *win32d.dll
>>>
>>> ok. I didn't dare to implement this, since we had some issues at finding
>>> libraries in the beginning. But if all dlls end in the win32.dll or
>>> win32d.dll
>>> suffix, there should be no problem in locating the right libraries.
>>>
>>> >
>>> > - In the same way as RTT, add the postfix "win32" to OCL targets (I
>>> > don't
>>> > know why this is actually done on gnulinux and not on win32?)
>>>
>>> Hmm. This is because of the UseOrocos.cmake macros. That would be a bug
>>> then...
>>>
>>> >
>>> >
>>> > Before submitting any patches, I would appreciate to have comments from
>>> > Peter and maybe some Windows users.
>>>
>>> I can certainly help with cross-checking your patches.
>>>
>>
>> Here the first set of patches for RTT to solve all these problemes. The
>> ones for OCL will follow in the next email. They have been generated from
>> the v2.3.1 tag. I hope this won't give you much problems.
>> Philippe
>
> Here is the second set of patches and these ones are for OCL. Again, they
> have been generated from the v2.3.1 tag. I hope this won't give you much
> problems. I have also fixed a linking problem with readline for windows.
> There's a problem with pre-compiled binaries of readline (coming from the
> Wiki), because the debug version of readline is linking with both debug and
> release CRT. Just downloading the sources and re-compiling both of them
> solve the problem.
> Philippe

Thanks. I'll review and apply asap, probably next wednesday.

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

Many oroblems while mixing build configurations on win32

Submitted by vri on Tue, 2011-05-31 07:16.

2011/5/31 Peter Soetens <peter [..] ...>:
> On Fri, May 27, 2011 at 9:58 PM, Philippe Hamelin
> <philippe [dot] hamelin [..] ...> wrote:
>> 2011/5/27 Philippe Hamelin <philippe [dot] hamelin [..] ...>
>>>
>>> 2011/5/26 Peter Soetens <peter [..] ...>
>>>>
>>>> On Wednesday 25 May 2011 18:43:47 Philippe Hamelin wrote:
>>>> > Hello,
>>>> >
>>>> > there's some problems when using multiple configurations (e.g., debug
>>>> > and
>>>> > release) of RTT and OCL on win32 on the same install path.
>>>> >
>>>> >
>>>> > *** PROBLEM 1: OCL executables names
>>>> >
>>>> > Actually, when building RTT and OCL in debug on win32, the postfix
"d"
>>>> > is
>>>> > added to library names. However, this isn't the case for executables.
>>>> > So,
>>>> > in the case both debug and release binaries are installed, debug or
>>>> > release executables are just overwrited.
>>>> >
>>>> >
>>>> > *** PROBLEM 2: OCL linking problem
>>>> >
>>>> > When both configurations of RTT (debug/release) are build and
installed
>>>> > in
>>>> > the same directory, the OCL FindRTTPlugin link with both libraries if
>>>> > they
>>>> > are found. The problem is clearer when looking at this snippet of
>>>> > FindRTTPlugin.cmake :
>>>> >
>>>> >

>>>> >
>>>> >     if ( RTT_PLUGIN_${COMPONENT}D_LIBRARY )
>>>> >       list(APPEND RTT_PLUGIN_${COMPONENT}_PROCESS_LIBS
>>>> > RTT_PLUGIN_${COMPONENT}D_LIBRARY)
>>>> >     endif()
>>>> >     if ( RTT_PLUGIN_${COMPONENT}_LIBRARY )
>>>> >       list(APPEND RTT_PLUGIN_${COMPONENT}_PROCESS_LIBS
>>>> > RTT_PLUGIN_${COMPONENT}_LIBRARY)
>>>> >     endif()
>>>> >
>>>> >

>>>> >
>>>> >
>>>> > *** PROBLEM 3: RTT try to load both debug and release libraries
>>>> >
>>>> > If both debug and release components are installed in the
>>>> > RTT_COMPONENT_PATH, RTT tries to load both and this lead to a C++
>>>> > exception.
>>>> >
>>>> >
>>>> >
>>>> > No ones of these problems appear if we use a single configuration or
if
>>>> > we
>>>> > install the configurations in different paths. In my opinion, this is
>>>> > not
>>>> > an option since we want to be able to "Find(Orocos)" and then use the
>>>> > drop
>>>> > box in Visual Studio to select which configuration to build. If they
>>>> > are
>>>> > installed on different directories then this will be a big headache
to
>>>> > maintain the CMake logic.
>>>> >
>>>> > Here is my proposition (only apply to win32 target):
>>>> >
>>>> > - Modify the FindRTTPlugin to use "debug" and "optimized" keywords in
>>>> > order
>>>> > to link only with one configuration and not both
>>>>
>>>> ok.
>>>>
>>>> > - Add the postfix "d" to the executables, so they can both live in
the
>>>> > same
>>>> > binary installation folder
>>>>
>>>> ok.
>>>>
>>>> > - Add a filter in the plugins/typekit/components loader to only load
>>>> > the
>>>> > appropriate DLLs, i.e. :
>>>> >
>>>> > deployer-win32 only loads *win32.dll
>>>> > deployer-win32d only loads *win32d.dll
>>>>
>>>> ok. I didn't dare to implement this, since we had some issues at
finding
>>>> libraries in the beginning. But if all dlls end in the win32.dll or
>>>> win32d.dll
>>>> suffix, there should be no problem in locating the right libraries.
>>>>
>>>> >
>>>> > - In the same way as RTT, add the postfix "win32" to OCL targets (I
>>>> > don't
>>>> > know why this is actually done on gnulinux and not on win32?)
>>>>
>>>> Hmm. This is because of the UseOrocos.cmake macros. That would be a bug
>>>> then...
>>>>
>>>> >
>>>> >
>>>> > Before submitting any patches, I would appreciate to have comments
from
>>>> > Peter and maybe some Windows users.
>>>>
>>>> I can certainly help with cross-checking your patches.
>>>>
>>>
>>> Here the first set of patches for RTT to solve all these problemes. The
>>> ones for OCL will follow in the next email. They have been generated
from
>>> the v2.3.1 tag. I hope this won't give you much problems.
>>> Philippe
>>
>> Here is the second set of patches and these ones are for OCL. Again, they
>> have been generated from the v2.3.1 tag. I hope this won't give you much
>> problems. I have also fixed a linking problem with readline for windows.
>> There's a problem with pre-compiled binaries of readline (coming from the
>> Wiki), because the debug version of readline is linking with both debug
and
>> release CRT. Just downloading the sources and re-compiling both of them
>> solve the problem.
>> Philippe
>
> Thanks. I'll review and apply asap, probably next wednesday.
>
> Peter
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

So the number of OROblems in OROcos is decreasing steadily [?]

Orocos Real-Time Toolkit

Many oroblems while mixing build configurations on win32

Many oroblems while mixing build configurations on win32

Many oroblems while mixing build configurations on win32

Many oroblems while mixing build configurations on win32

Many oroblems while mixing build configurations on win32

Many oroblems while mixing build configurations on win32