For Ubuntu Gutsy with TAO as package.
Hope the patch stays intact ...
Index: config/FindTAO.cmake
===================================================================
--- config/FindTAO.cmake (revision 29992)
+++ config/FindTAO.cmake (working copy)
@@ -81,20 +81,20 @@
# Set include/link variables
IF( NOT ${ACE_DIR} STREQUAL /usr )
- LIST(APPEND CORBA_INCLUDES ${ACE_DIR}/include)
+ LIST(APPEND CORBA_INCLUDE_DIRS "${ACE_DIR}/include")
LIST(APPEND CORBA_CFLAGS "-I${ACE_DIR}/include")
LIST(APPEND CORBA_LINK_DIRECTORIES "${ACE_DIR}/lib")
LIST(APPEND CORBA_LDFLAGS "-L${ACE_DIR}/lib")
ENDIF( NOT ${ACE_DIR} STREQUAL /usr )
IF( NOT ${TAO_DIR} STREQUAL /usr AND NOT ${TAO_DIR} STREQUAL ${ACE_DIR})
- LIST(APPEND CORBA_INCLUDES ${TAO_DIR}/include)
+ LIST(APPEND CORBA_INCLUDE_DIRS "${TAO_DIR}/include")
LIST(APPEND CORBA_CFLAGS "-I${TAO_DIR}/include")
LIST(APPEND CORBA_LINK_DIRECTORIES "${TAO_DIR}/lib")
LIST(APPEND CORBA_LDFLAGS "-L${TAO_DIR}/lib")
ENDIF( NOT ${TAO_DIR} STREQUAL /usr AND NOT ${TAO_DIR} STREQUAL ${ACE_DIR})
IF( NOT ${ORBSVCS_DIR} STREQUAL /usr AND NOT ${ORBSVCS_DIR} STREQUAL ${TAO_DIR})
- LIST(APPEND CORBA_INCLUDES ${ORBSVCS_DIR}/include)
- LIST(APPEND CORBA_CFLAGS "-I${ORBSVCS_DIR}/include")
+ LIST(APPEND CORBA_INCLUDE_DIRS "${ORBSVCS_DIR}")
+ LIST(APPEND CORBA_CFLAGS "-I${ORBSVCS_DIR}")
LIST(APPEND CORBA_LINK_DIRECTORIES "${ORBSVCS_DIR}/lib")
LIST(APPEND CORBA_LDFLAGS "-L${ORBSVCS_DIR}/lib")
ENDIF( NOT ${ORBSVCS_DIR} STREQUAL /usr AND NOT ${ORBSVCS_DIR} STREQUAL ${TAO_DIR})
Find TAO cmake broken
Another patch for RTT, so can build deployer-corba.
Find TAO cmake broken
This is the only way I can get this to work. You have to force the list into a string first, due to the use of RTT_CORBA_CFLAGS within a string with the COMPILE_FLAGS property in SET_TARGET_PROPERTIES of orocs-rtt-corba-dynamic-TARGET. We have to embed a string, not a list.
Works for Cmake 2.4 under Ubuntu Hardy with ACE/TAO in standard install location. Also works for CMake 2.6 under Mac Leopard with ACE/TAO in non-standard install location. I believe the overall problem will *only* show up with non-standard install locations.
If others can reproduce this, then IMHO this leads us towards not mixing CMake lists and strings throughout our build files.
Find TAO cmake broken
On Wednesday 25 February 2009 04:52:43 kiwi [dot] net [..] ... wrote:
> This is the only way I can get this to work. You have to force the list
> into a string first, due to the use of RTT_CORBA_CFLAGS within a string
> with the COMPILE_FLAGS property in SET_TARGET_PROPERTIES of
> orocs-rtt-corba-dynamic-TARGET. We have to embed a string, not a list.
So the patch from Ruben on 18/02/09 did not work for you ? Ruben's is a bit
cleaner, but if it doesn't do it, I'll apply yours.
Peter
Find TAO cmake broken
On Feb 25, 2009, at 16:26 , Peter Soetens wrote:
> On Wednesday 25 February 2009 04:52:43 kiwi [dot] net [..] ... wrote:
>> This is the only way I can get this to work. You have to force the
>> list
>> into a string first, due to the use of RTT_CORBA_CFLAGS within a
>> string
>> with the COMPILE_FLAGS property in SET_TARGET_PROPERTIES of
>> orocs-rtt-corba-dynamic-TARGET. We have to embed a string, not a
>> list.
>
> So the patch from Ruben on 18/02/09 did not work for you ? Ruben's
> is a bit
> cleaner, but if it doesn't do it, I'll apply yours.
No, Ruben's didn't do it. And looking at it in detail in CMake 2.6, I
can't see how his patch can solve all the issues. Not unless someone
knows a way to convert a list to a string _while_ it is being inserted
into a string. The problem is this
SET(xxx a b c) ** xxx = "a;b;c"
SET_TARGET_PROPERTIES(yyy
...
COMPILE_FLAGS "${a1} ${a2} ${xxx} ${b1}"
...
where the xxx substitution comes in literally as "a;b;c" which doesn't
work in the middle of a bunch of compiler flags.
Changing to
COMPILE_FLAGS "${a1} ${a2} " ${xxx} " ${b1}"
causes problems as now CMake thinks that some of a;b;c are additional
properties for SET_TARGET_PROPERTIES.
I think you either separate out all the flags and individually do a
COMPILE_FLAGS for each, which is not possible here, or you use STRING
lists everywhere and don't use LISTs (which do have their uses), or
you muck around with forcing lists to come out as individual string
components into our STRING lists (as I've done here, though it is ugly).
Anyone know of an alternative?
S
Find TAO cmake broken
On Feb 25, 2009, at 17:20 , Stephen Roderick wrote:
> On Feb 25, 2009, at 16:26 , Peter Soetens wrote:
>
>> On Wednesday 25 February 2009 04:52:43 kiwi [dot] net [..] ... wrote:
>>> This is the only way I can get this to work. You have to force the
>>> list
>>> into a string first, due to the use of RTT_CORBA_CFLAGS within a
>>> string
>>> with the COMPILE_FLAGS property in SET_TARGET_PROPERTIES of
>>> orocs-rtt-corba-dynamic-TARGET. We have to embed a string, not a
>>> list.
>>
>> So the patch from Ruben on 18/02/09 did not work for you ? Ruben's
>> is a bit
>> cleaner, but if it doesn't do it, I'll apply yours.
>
> No, Ruben's didn't do it. And looking at it in detail in CMake 2.6, I
> can't see how his patch can solve all the issues. Not unless someone
> knows a way to convert a list to a string _while_ it is being inserted
> into a string. The problem is this
>
> SET(xxx a b c) ** xxx = "a;b;c"
>
> SET_TARGET_PROPERTIES(yyy
> ...
> COMPILE_FLAGS "${a1} ${a2} ${xxx} ${b1}"
> ...
>
> where the xxx substitution comes in literally as "a;b;c" which doesn't
> work in the middle of a bunch of compiler flags.
>
> Changing to
>
> COMPILE_FLAGS "${a1} ${a2} " ${xxx} " ${b1}"
>
> causes problems as now CMake thinks that some of a;b;c are additional
> properties for SET_TARGET_PROPERTIES.
>
> I think you either separate out all the flags and individually do a
> COMPILE_FLAGS for each, which is not possible here, or you use STRING
> lists everywhere and don't use LISTs (which do have their uses), or
> you muck around with forcing lists to come out as individual string
> components into our STRING lists (as I've done here, though it is
> ugly).
>
> Anyone know of an alternative?
> S
Further patch needed for LDFLAGS when TAO in non-standard install
directory. Fixes same problem re mixed LIST/STRING variables. Tested
on Mac + non-standard install, plus gnulinux with packaged install.
The macro should probably go in a global file?
I still maintain that we should choose one or the other: either use
LISTs or STRINGs in our CMake files, but *NOT* both. Thoughts?
S
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
New CMAKE convention (Was: Find TAO cmake broken)
On Saturday 21 March 2009 18:08:16 S Roderick wrote:
>
> Further patch needed for LDFLAGS when TAO in non-standard install
> directory. Fixes same problem re mixed LIST/STRING variables. Tested
> on Mac + non-standard install, plus gnulinux with packaged install.
>
> The macro should probably go in a global file?
Yes.
>
> I still maintain that we should choose one or the other: either use
> LISTs or STRINGs in our CMake files, but *NOT* both. Thoughts?
We should use LIST in cmake code and only convert to string when outputting
to a file/format that requires a string. CMAKE offers macros for manipulating
lists that make LIST more natural to use. Your macro is ideal for supporting
that convention. Ideally we should *never* need a STRING2LIST macro.
Maintainers/contributors: please ACK that you got this convention.
Peter
New CMAKE convention (Was: Find TAO cmake broken)
On Mar 24, 2009, at 05:51 , Peter Soetens wrote:
> On Saturday 21 March 2009 18:08:16 S Roderick wrote:
>>
>> Further patch needed for LDFLAGS when TAO in non-standard install
>> directory. Fixes same problem re mixed LIST/STRING variables. Tested
>> on Mac + non-standard install, plus gnulinux with packaged install.
>>
>> The macro should probably go in a global file?
>
> Yes.
You? Me?
>> I still maintain that we should choose one or the other: either use
>> LISTs or STRINGs in our CMake files, but *NOT* both. Thoughts?
>
> We should use LIST in cmake code and only convert to string when
> outputting
> to a file/format that requires a string. CMAKE offers macros for
> manipulating
> lists that make LIST more natural to use. Your macro is ideal for
> supporting
> that convention. Ideally we should *never* need a STRING2LIST macro.
>
> Maintainers/contributors: please ACK that you got this convention.
So presumably
a) all NEW CMake code must use lists
b) how do we deal with existing CMake code?
Otherwise, ACK.
S
New CMAKE convention (Was: Find TAO cmake broken)
On Tuesday 24 March 2009 13:30:24 S Roderick wrote:
> On Mar 24, 2009, at 05:51 , Peter Soetens wrote:
> > On Saturday 21 March 2009 18:08:16 S Roderick wrote:
> >> Further patch needed for LDFLAGS when TAO in non-standard install
> >> directory. Fixes same problem re mixed LIST/STRING variables. Tested
> >> on Mac + non-standard install, plus gnulinux with packaged install.
> >>
> >> The macro should probably go in a global file?
> >
> > Yes.
>
> You? Me?
Put it in config/rtt_macros.cmake ? Well, since you're on it :-)
>
> >> I still maintain that we should choose one or the other: either use
> >> LISTs or STRINGs in our CMake files, but *NOT* both. Thoughts?
> >
> > We should use LIST in cmake code and only convert to string when
> > outputting
> > to a file/format that requires a string. CMAKE offers macros for
> > manipulating
> > lists that make LIST more natural to use. Your macro is ideal for
> > supporting
> > that convention. Ideally we should *never* need a STRING2LIST macro.
> >
> > Maintainers/contributors: please ACK that you got this convention.
>
> So presumably
>
> a) all NEW CMake code must use lists
> b) how do we deal with existing CMake code?
Unless someone volunteers for an all-at-once, it'll need to be fixed along as
we go. The CMakeCache.txt is a good indicator to identify (the cached)
good/bad cases. Looking at it, it seems CMAKE_*_FLAGS_* are all strings by
CMake convention; our RTT_*FLAGS are strings too, but should be replaced by a
list equivalent (but see also[*]). All *_INCLUDE_DIRS and *_LIBRARIES should
be or are already lists.
It would be better if we found some notational convention to distinguish LISTS
from STRINGS. Then there's also the issue if a list of include/link
directories should already contain the -I/-L prefix or would this only be added
in the last step (extra optional argument of LIST2STRING) ?
[*] Finally, about the RTT_*FLAGS, they capture flags 'along the way' (for
generating the .pc file for example). This messes at some places with the
convention that flag detection and flag use should be separated. This was also
caused by part of the configuration done in config/global_setup.cmake and part
in src/CMakeLists.txt. We should pick one or the other.
So:
a. 1 central file for detecting build environment
b. 1 central file for toggling the options and influencing the build flags/lists
c. the CMakeLists.txt files just use the stuff from b.
Just a suggestion...needs more work.
Peter
New CMAKE convention (Was: Find TAO cmake broken)
> Unless someone volunteers for an all-at-once, it'll need to be fixed along as
> we go. The CMakeCache.txt is a good indicator to identify (the cached)
> good/bad cases. Looking at it, it seems CMAKE_*_FLAGS_* are all strings by
> CMake convention; our RTT_*FLAGS are strings too, but should be replaced by a
> list equivalent (but see also[*]). All *_INCLUDE_DIRS and *_LIBRARIES should
> be or are already lists.
>
> It would be better if we found some notational convention to distinguish LISTS
> from STRINGS.
I'm not sure that is needed. Everything should be list. Period. A one-element
list is a string anyway for CMake.
> Then there's also the issue if a list of include/link
> directories should already contain the -I/-L prefix or would this only be added
> in the last step (extra optional argument of LIST2STRING) ?
include and link directories lists should never include -I and -L since they
should be used with CMake's INCLUDE_DIRECTORIES and LINK_DIRECTORIES calls.
> [*] Finally, about the RTT_*FLAGS, they capture flags 'along the way' (for
> generating the .pc file for example). This messes at some places with the
> convention that flag detection and flag use should be separated. This was also
> caused by part of the configuration done in config/global_setup.cmake and part
> in src/CMakeLists.txt. We should pick one or the other.
I think that they should be dropped altogether, and the final list of flags (for
.pc or other stuff) should be built where it is needed. That will avoid weird
issues in the end.
Sylvain
New CMAKE convention (Was: Find TAO cmake broken)
On Wednesday 25 March 2009 10:46:37 Sylvain Joyeux wrote:
> > Unless someone volunteers for an all-at-once, it'll need to be fixed
> > along as we go. The CMakeCache.txt is a good indicator to identify (the
> > cached) good/bad cases. Looking at it, it seems CMAKE_*_FLAGS_* are all
> > strings by CMake convention; our RTT_*FLAGS are strings too, but should
> > be replaced by a list equivalent (but see also[*]). All *_INCLUDE_DIRS
> > and *_LIBRARIES should be or are already lists.
> >
> > It would be better if we found some notational convention to distinguish
> > LISTS from STRINGS.
>
> I'm not sure that is needed. Everything should be list. Period. A
> one-element list is a string anyway for CMake.
ACK.
>
> > Then there's also the issue if a list of include/link
> > directories should already contain the -I/-L prefix or would this only be
> > added in the last step (extra optional argument of LIST2STRING) ?
>
> include and link directories lists should never include -I and -L since
> they should be used with CMake's INCLUDE_DIRECTORIES and LINK_DIRECTORIES
> calls.
ACK.
>
> > [*] Finally, about the RTT_*FLAGS, they capture flags 'along the way'
> > (for generating the .pc file for example). This messes at some places
> > with the convention that flag detection and flag use should be separated.
> > This was also caused by part of the configuration done in
> > config/global_setup.cmake and part in src/CMakeLists.txt. We should pick
> > one or the other.
>
> I think that they should be dropped altogether, and the final list of flags
> (for .pc or other stuff) should be built where it is needed. That will
> avoid weird issues in the end.
ACK.
Peter
pkgconfig missing -L for ACE, xerces and boost
Hi,
I'm a bit lost on this. Is this issue closed for orocos-rtt 1.8.2? At least the rtt pkgconfig is still incomplete, as it contains the include paths for boost, xerces, ace and tao, but does not contain any library path for these libraries.
This is what I get:
===================orocos-rtt-gnulinux.pc========
prefix=/opt/orocos-rtt-1.8.2_boost138
exec_prefix=${prefix} # defining another variable in terms of the first
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: Orocos-RTT # human-readable name
Description: Open Robot Control Software: Real-Time Tookit # human-readable description
Version: 1.8.2
Libs: -L${libdir} -lorocos-rtt-gnulinux -lpthread
Libs.private: -lrt -lxerces-c -lxerces-c
Cflags: -I${includedir} -DOROCOS_TARGET=gnulinux -I/opt/boost_1_38/include -I/opt/xercesc/include
===================orocos-rtt-corba-gnulinux.pc========
prefix=/opt/orocos-rtt-1.8.2_boost138
exec_prefix=${prefix} # defining another variable in terms of the first
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: Orocos-RTT-CORBA # human-readable name
Description: Open Robot Control Software: Real-Time Tookit # human-readable description
Requires: orocos-rtt-gnulinux
Version: 1.8.2
Libs: -L${libdir} -lorocos-rtt-corba-gnulinux
Libs.private:
Cflags: -I/opt/boost_1_38/include -I/opt/xercesc/include -I/opt/ACE_wrappers/include -I/dataServers/trac/tmp/Orocos/ACE_wrappers/TAO/include -I/dataServers/trac/tmp/Orocos/ACE_wrappers/TAO/include/orbsvcs -I${includedir}/rtt/corba
thanks
pkgconfig missing -L for ACE, xerces and boost
On Tuesday 21 April 2009 10:38:50 orocos [..] ... wrote:
> Hi,
> I'm a bit lost on this. Is this issue closed for orocos-rtt 1.8.2? At least
> the rtt pkgconfig is still incomplete, as it contains the include paths for
> boost, xerces, ace and tao, but does not contain any library path for these
> libraries.
Thanks for reporting. If you want to keep this issue open, submit a bug
report. I don't recall that it was fixed, I remember a patch in the queue that
fixes some CMake logic. I'm quite overloaded during the remainder of april, so
if someone wants to collect the necessary patches and test them for this
situation, it will help accepting them faster.
Peter
rpath for OCL installed binaries
Another program we have is that when the OCL binaries are linked, the rpath is correctly set. However, when we run "make install", the rpath is removed (cmake actually says "Removed runtime path). This is not so what if you use pkgconfig for linking against OCL (if the pkgconfig is manually fixed), but if you just try to run deployer-gnulinux, it will fail because it does not find the rtt libs
deployer-gnulinux: error while loading shared libraries: liborocos-rtt-gnulinux.so.1.8: cannot open shared object file: No such file or directory
We have solved this problem adding this to the orocos OCL cmake:
rpath for OCL installed binaries
On Tuesday 21 April 2009 17:49:59 orocos [..] ... wrote:
> Another program we have is that when the OCL binaries are linked, the rpath
> is correctly set. However, when we run "make install", the rpath is removed
> (cmake actually says "Removed runtime path). This is not so what if you use
> pkgconfig for linking against OCL (if the pkgconfig is manually fixed), but
> if you just try to run deployer-gnulinux, it will fail because it does not
> find the rtt libs
We work around this by setting
export LD_LIBRARY_PATH=/opt/orocos/lib
or put the path in a file in the /etc/ld.so.conf.d/ directory or as a line in
the /etc/ld.so.conf file.
or similar. I'm not sure if your work-around by setting the rpath is
acceptable practice. I believe other libraries would not set the rpath either
when they are installed. Anyone ?
Peter
rpath for OCL installed binaries
On Wed, Apr 22, 2009 at 11:05 PM, Peter Soetens <peter [dot] soetens [..] ...>wrote:
> On Tuesday 21 April 2009 17:49:59 orocos [..] ... wrote:
> > Another program we have is that when the OCL binaries are linked, the
> rpath
> > is correctly set. However, when we run "make install", the rpath is
> removed
> > (cmake actually says "Removed runtime path). This is not so what if you
> use
> > pkgconfig for linking against OCL (if the pkgconfig is manually fixed),
> but
> > if you just try to run deployer-gnulinux, it will fail because it does
> not
> > find the rtt libs
>
> We work around this by setting
> export LD_LIBRARY_PATH=/opt/orocos/lib
> or put the path in a file in the /etc/ld.so.conf.d/ directory or as a line
> in
> the /etc/ld.so.conf file.
>
> or similar. I'm not sure if your work-around by setting the rpath is
> acceptable practice. I believe other libraries would not set the rpath
> either
> when they are installed. Anyone ?
What do you mean by other libraries?
Rpath settings can be tuned so that your development and installation trees
correctly find third party and own project shared libs when they are not in
a standard location (nor specified in one of the above files you mention
above).
Now that we're discussing rpath settings, I have two observations on the
subject:
- I wouldn't hardcode rpath settings on the Orocos build system because
users may be interested in different setups. for example, when we
cross-compile, we use quite a different setup than for local builds. You can
however specify them for a particular build by invoking cmake as 'cmake -C
myRpathSettings.cmake'. Also note that the rpath settings proposed in the
top post require a second linking step at install time (to be able to
resolve own-project shared libs in the installation tree).
- Orocos OCL components are dynamically loaded libraries, which are not
known at compile-time, and rpath settings do not seem to work with them. We
need to use LD_LIBRARY_PATH or any of the other alternatives to set the
(nonstandard) location of our components.
How do other Orocos users go around with this issue?
>
>
> Peter
> --
> Peter Soetens -- FMTC -- <http://www.fmtc.be>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
Find TAO cmake broken
For Ubuntu Gutsy with TAO as package.
Hope the patch stays intact ...
Find TAO cmake broken
Another patch for RTT, so can build deployer-corba.
Find TAO cmake broken
This is the only way I can get this to work. You have to force the list into a string first, due to the use of RTT_CORBA_CFLAGS within a string with the COMPILE_FLAGS property in SET_TARGET_PROPERTIES of orocs-rtt-corba-dynamic-TARGET. We have to embed a string, not a list.
Works for Cmake 2.4 under Ubuntu Hardy with ACE/TAO in standard install location. Also works for CMake 2.6 under Mac Leopard with ACE/TAO in non-standard install location. I believe the overall problem will *only* show up with non-standard install locations.
If others can reproduce this, then IMHO this leads us towards not mixing CMake lists and strings throughout our build files.
Find TAO cmake broken
On Tuesday 17 February 2009 20:28:53 kiwi [dot] net [..] ... wrote:
> Another patch for RTT, so can build deployer-corba.
Applied both patches. strange that I didn't catch these on my Ubuntu Intrepid
and Debian Etch(+testing) systems...
Peter
Find TAO cmake broken
I cannot build rtt-corba anymore since the latest patches:
[ 76%] Building CXX object src/corba/CMakeFiles/orocos-rtt-corba_dynamic-lxrt.dir/AttributesI.o
/usr/bin/c++ -DRTT_DLL_EXPORT -O2 -DNDEBUG -fPIC -I/usr/realtime/include -I/include -I/usr/local/src/rtt/src -I/usr/local/src/rtt/build-lxrt/src -I/usr/local/src/rtt/build-lxrt/src/os -I/usr/local/src/rtt/build-lxrt/src/os/lxrt -I/usr/include/orbsvcs -I/usr/local/src/rtt/build-lxrt/src/corba -Wall -I/usr/realtime/include -I/include -I/usr/realtime/include -I/include;-I/usr/include/orbsvcs -D_REENTRANT -DOROCOS_TARGET=lxrt -o src/corba/CMakeFiles/orocos-rtt-corba_dynamic-lxrt.dir/AttributesI.o -c /usr/local/src/rtt/src/corba/AttributesI.cpp
c++: no input files
/bin/sh: -I/usr/include/orbsvcs: not found
make[2]: *** [src/corba/CMakeFiles/orocos-rtt-corba_dynamic-lxrt.dir/AttributesI.o] Error 127
Ruben
________________________________________
From: orocos-dev-bounces [..] ... [orocos-dev-bounces [..] ...] On Behalf Of Peter Soetens [Peter [dot] Soetens [..] ...]
Sent: Wednesday, February 18, 2009 11:01
To: orocos-dev [..] ...; kiwi [dot] net [..] ...
Subject: Re: [Orocos-Dev] Find TAO cmake broken
On Tuesday 17 February 2009 20:28:53 kiwi [dot] net [..] ... wrote:
> Another patch for RTT, so can build deployer-corba.
Applied both patches. strange that I didn't catch these on my Ubuntu Intrepid
and Debian Etch(+testing) systems...
Peter
--
Peter Soetens -- FMTC -- <http://www.fmtc.be>
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Find TAO cmake broken
It is due to the semi-colon (;) between the include flags, i do not know where is comes from.
Ruben
________________________________________
From: orocos-dev-bounces [..] ... [orocos-dev-bounces [..] ...] On Behalf Of Ruben Smits [Ruben [dot] Smits [..] ...]
Sent: Wednesday, February 18, 2009 14:13
To: orocos-dev [..] ...
Subject: Re: [Orocos-Dev] Find TAO cmake broken
I cannot build rtt-corba anymore since the latest patches:
[ 76%] Building CXX object src/corba/CMakeFiles/orocos-rtt-corba_dynamic-lxrt.dir/AttributesI.o
/usr/bin/c++ -DRTT_DLL_EXPORT -O2 -DNDEBUG -fPIC -I/usr/realtime/include -I/include -I/usr/local/src/rtt/src -I/usr/local/src/rtt/build-lxrt/src -I/usr/local/src/rtt/build-lxrt/src/os -I/usr/local/src/rtt/build-lxrt/src/os/lxrt -I/usr/include/orbsvcs -I/usr/local/src/rtt/build-lxrt/src/corba -Wall -I/usr/realtime/include -I/include -I/usr/realtime/include -I/include;-I/usr/include/orbsvcs -D_REENTRANT -DOROCOS_TARGET=lxrt -o src/corba/CMakeFiles/orocos-rtt-corba_dynamic-lxrt.dir/AttributesI.o -c /usr/local/src/rtt/src/corba/AttributesI.cpp
c++: no input files
/bin/sh: -I/usr/include/orbsvcs: not found
make[2]: *** [src/corba/CMakeFiles/orocos-rtt-corba_dynamic-lxrt.dir/AttributesI.o] Error 127
Ruben
________________________________________
From: orocos-dev-bounces [..] ... [orocos-dev-bounces [..] ...] On Behalf Of Peter Soetens [Peter [dot] Soetens [..] ...]
Sent: Wednesday, February 18, 2009 11:01
To: orocos-dev [..] ...; kiwi [dot] net [..] ...
Subject: Re: [Orocos-Dev] Find TAO cmake broken
On Tuesday 17 February 2009 20:28:53 kiwi [dot] net [..] ... wrote:
> Another patch for RTT, so can build deployer-corba.
Applied both patches. strange that I didn't catch these on my Ubuntu Intrepid
and Debian Etch(+testing) systems...
Peter
--
Peter Soetens -- FMTC -- <http://www.fmtc.be>
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Find TAO cmake broken
On Wednesday 25 February 2009 23:20:00 Stephen Roderick wrote:
> On Feb 25, 2009, at 16:26 , Peter Soetens wrote:
> > On Wednesday 25 February 2009 04:52:43 kiwi [dot] net [..] ... wrote:
> >> This is the only way I can get this to work. You have to force the
> >> list
> >> into a string first, due to the use of RTT_CORBA_CFLAGS within a
> >> string
> >> with the COMPILE_FLAGS property in SET_TARGET_PROPERTIES of
> >> orocs-rtt-corba-dynamic-TARGET. We have to embed a string, not a
> >> list.
> >
> > So the patch from Ruben on 18/02/09 did not work for you ? Ruben's
> > is a bit
> > cleaner, but if it doesn't do it, I'll apply yours.
>
> No, Ruben's didn't do it. And looking at it in detail in CMake 2.6, I
> can't see how his patch can solve all the issues. Not unless someone
> knows a way to convert a list to a string _while_ it is being inserted
> into a string. The problem is this
>
> SET(xxx a b c) ** xxx = "a;b;c"
>
> SET_TARGET_PROPERTIES(yyy
> ...
> COMPILE_FLAGS "${a1} ${a2} ${xxx} ${b1}"
> ...
>
> where the xxx substitution comes in literally as "a;b;c" which doesn't
> work in the middle of a bunch of compiler flags.
>
> Changing to
>
> COMPILE_FLAGS "${a1} ${a2} " ${xxx} " ${b1}"
>
> causes problems as now CMake thinks that some of a;b;c are additional
> properties for SET_TARGET_PROPERTIES.
>
> I think you either separate out all the flags and individually do a
> COMPILE_FLAGS for each, which is not possible here, or you use STRING
> lists everywhere and don't use LISTs (which do have their uses), or
> you muck around with forcing lists to come out as individual string
> components into our STRING lists (as I've done here, though it is ugly).
>
> Anyone know of an alternative?
Automake :-)
Just kidding. Maybe a for loop could iterate over the list and add in the loop
each element of the string ? It's not that a different hack than the ';'
replace, but it has an odour of cleaniness around it.
Peter
Find TAO cmake broken
On Feb 25, 2009, at 17:47 , Peter Soetens wrote:
> On Wednesday 25 February 2009 23:20:00 Stephen Roderick wrote:
>> On Feb 25, 2009, at 16:26 , Peter Soetens wrote:
>>> On Wednesday 25 February 2009 04:52:43 kiwi [dot] net [..] ... wrote:
>>>> This is the only way I can get this to work. You have to force the
>>>> list
>>>> into a string first, due to the use of RTT_CORBA_CFLAGS within a
>>>> string
>>>> with the COMPILE_FLAGS property in SET_TARGET_PROPERTIES of
>>>> orocs-rtt-corba-dynamic-TARGET. We have to embed a string, not a
>>>> list.
>>>
>>> So the patch from Ruben on 18/02/09 did not work for you ? Ruben's
>>> is a bit
>>> cleaner, but if it doesn't do it, I'll apply yours.
>>
>> No, Ruben's didn't do it. And looking at it in detail in CMake 2.6, I
>> can't see how his patch can solve all the issues. Not unless someone
>> knows a way to convert a list to a string _while_ it is being
>> inserted
>> into a string. The problem is this
>>
>> SET(xxx a b c) ** xxx = "a;b;c"
>>
>> SET_TARGET_PROPERTIES(yyy
>> ...
>> COMPILE_FLAGS "${a1} ${a2} ${xxx} ${b1}"
>> ...
>>
>> where the xxx substitution comes in literally as "a;b;c" which
>> doesn't
>> work in the middle of a bunch of compiler flags.
>>
>> Changing to
>>
>> COMPILE_FLAGS "${a1} ${a2} " ${xxx} " ${b1}"
>>
>> causes problems as now CMake thinks that some of a;b;c are
>> additional
>> properties for SET_TARGET_PROPERTIES.
>>
>> I think you either separate out all the flags and individually do a
>> COMPILE_FLAGS for each, which is not possible here, or you use STRING
>> lists everywhere and don't use LISTs (which do have their uses), or
>> you muck around with forcing lists to come out as individual string
>> components into our STRING lists (as I've done here, though it is
>> ugly).
>>
>> Anyone know of an alternative?
>
> Automake :-)
>
> Just kidding. Maybe a for loop could iterate over the list and add
> in the loop
> each element of the string ? It's not that a different hack than the
> ';'
> replace, but it has an odour of cleaniness around it.
Actually, things are worse than we thought. The assumption on what
ACE_ROOT/TAO_ROOT is now different from RTT to KDL. RTT appears to
want "/path/to/" whereas KDL wants "/path/to/include". You can see
this by comparing what they set ACE_DIR to as a default, in rtt/config/
FindTAO.cmake and kdl/config/FindCorbaDeps.cmake. This is all on trunk
at r30015
Why are we not using the same approach? Better yet, why aren't we
using the same file for each?
Again, I think this *only* crops up for those of us with non-standard
install locations. This pushes me again to suggest that we ditch *ALL*
explicit references to install dir's, and just use CMake's standard
approaches (either through CMAKE_INCLUDE_PATH, etc, or through a CMake
project configuration file). At least with the standard approaches,
what people learn on other projects that follow the standard approach,
will apply directly here. There won't be any "magic" involved ...
It also make me think that we should think about instituting automated
daily builds ... might catch some of these earlier ...
Thoughts?
S
Find TAO cmake broken
On Tuesday 03 March 2009 02:30:15 Stephen Roderick wrote:
> Actually, things are worse than we thought. The assumption on what
> ACE_ROOT/TAO_ROOT is now different from RTT to KDL. RTT appears to
> want "/path/to/" whereas KDL wants "/path/to/include". You can see
> this by comparing what they set ACE_DIR to as a default, in rtt/config/
> FindTAO.cmake and kdl/config/FindCorbaDeps.cmake. This is all on trunk
> at r30015
>
> Why are we not using the same approach? Better yet, why aren't we
> using the same file for each?
They are/were/should. The KDL people 'should' regularily copy these files over
from the RTT and use them.
>
> Again, I think this *only* crops up for those of us with non-standard
> install locations. This pushes me again to suggest that we ditch *ALL*
> explicit references to install dir's, and just use CMake's standard
> approaches (either through CMAKE_INCLUDE_PATH, etc, or through a CMake
> project configuration file). At least with the standard approaches,
> what people learn on other projects that follow the standard approach,
> will apply directly here. There won't be any "magic" involved ...
I fully agree. However: the tao_idl program requires(d) ACE_ROOT and TAO_ROOT
to be set. If not, it could not compile certain idl files, for example those
that include the NamingService IDL. Also, gperf_ace is typically not found
when these paths are not set. In addition, the orbsvcs headers were sometimes
found in /usr/include/orbsvcs/orbsvcs or in /usr/include/orbsvcs. And then
there's other headers being moved or renamed. We were just trying to work
around the mess TAO is. I'm all in favour of using the standard CMAKE stuff,
but be aware to test these issues and change the installation manual.
>
> It also make me think that we should think about instituting automated
> daily builds ... might catch some of these earlier ...
We have, but it runs on standard Debian, with standard Debian/packages and
install locations.
Peter
Find TAO cmake broken
On Mar 3, 2009, at 03:43 , Peter Soetens wrote:
> On Tuesday 03 March 2009 02:30:15 Stephen Roderick wrote:
>> Actually, things are worse than we thought. The assumption on what
>> ACE_ROOT/TAO_ROOT is now different from RTT to KDL. RTT appears to
>> want "/path/to/" whereas KDL wants "/path/to/include". You can see
>> this by comparing what they set ACE_DIR to as a default, in rtt/
>> config/
>> FindTAO.cmake and kdl/config/FindCorbaDeps.cmake. This is all on
>> trunk
>> at r30015
>>
>> Why are we not using the same approach? Better yet, why aren't we
>> using the same file for each?
>
> They are/were/should. The KDL people 'should' regularily copy these
> files over
> from the RTT and use them.
>
>>
>> Again, I think this *only* crops up for those of us with non-standard
>> install locations. This pushes me again to suggest that we ditch
>> *ALL*
>> explicit references to install dir's, and just use CMake's standard
>> approaches (either through CMAKE_INCLUDE_PATH, etc, or through a
>> CMake
>> project configuration file). At least with the standard approaches,
>> what people learn on other projects that follow the standard
>> approach,
>> will apply directly here. There won't be any "magic" involved ...
>
> I fully agree. However: the tao_idl program requires(d) ACE_ROOT and
> TAO_ROOT
> to be set. If not, it could not compile certain idl files, for
> example those
> that include the NamingService IDL. Also, gperf_ace is typically not
> found
> when these paths are not set. In addition, the orbsvcs headers were
> sometimes
> found in /usr/include/orbsvcs/orbsvcs or in /usr/include/orbsvcs.
> And then
> there's other headers being moved or renamed. We were just trying to
> work
> around the mess TAO is. I'm all in favour of using the standard
> CMAKE stuff,
> but be aware to test these issues and change the installation manual.
I've noticed that problem with orbsvcs. You think they could just make
their mind up ...!
I have here both a standard Ubuntu install, plus a non-standard from
source install on the Mac . I'll take a look at correcting/simplifying
rtt/FindTAO. I also have an omniorb install, so I'll make sure that
doesn't break too.
>> It also make me think that we should think about instituting
>> automated
>> daily builds ... might catch some of these earlier ...
>
> We have, but it runs on standard Debian, with standard Debian/
> packages and
> install locations.
What are you using?
S
Find TAO cmake broken
On Tuesday 03 March 2009 13:52:16 Stephen Roderick wrote:
>
> I've noticed that problem with orbsvcs. You think they could just make
> their mind up ...!
>
> I have here both a standard Ubuntu install, plus a non-standard from
> source install on the Mac . I'll take a look at correcting/simplifying
> rtt/FindTAO. I also have an omniorb install, so I'll make sure that
> doesn't break too.
>
> >> It also make me think that we should think about instituting
> >> automated
> >> daily builds ... might catch some of these earlier ...
> >
> > We have, but it runs on standard Debian, with standard Debian/
> > packages and
> > install locations.
>
> What are you using?
My dev environment is Ubuntu 8.10 on AMD64. Our applications run on Debian
etch (i386). I'm setting up a new test system for Lenny as well.
Peter
Find TAO cmake broken
On Mar 3, 2009, at 10:38 , Peter Soetens wrote:
> On Tuesday 03 March 2009 13:52:16 Stephen Roderick wrote:
>>
>> I've noticed that problem with orbsvcs. You think they could just
>> make
>> their mind up ...!
>>
>> I have here both a standard Ubuntu install, plus a non-standard from
>> source install on the Mac . I'll take a look at correcting/
>> simplifying
>> rtt/FindTAO. I also have an omniorb install, so I'll make sure that
>> doesn't break too.
>>
>>>> It also make me think that we should think about instituting
>>>> automated
>>>> daily builds ... might catch some of these earlier ...
>>>
>>> We have, but it runs on standard Debian, with standard Debian/
>>> packages and
>>> install locations.
>>
>> What are you using?
>
> My dev environment is Ubuntu 8.10 on AMD64. Our applications run on
> Debian
> etch (i386). I'm setting up a new test system for Lenny as well.
What application are you using for the daily builds? CDash? Cruise
Control? Custom home grown scripts ...?
S
Find TAO cmake broken
On Tuesday 03 March 2009 21:56:58 Stephen Roderick wrote:
> On Mar 3, 2009, at 10:38 , Peter Soetens wrote:
> > On Tuesday 03 March 2009 13:52:16 Stephen Roderick wrote:
> >> I've noticed that problem with orbsvcs. You think they could just
> >> make
> >> their mind up ...!
> >>
> >> I have here both a standard Ubuntu install, plus a non-standard from
> >> source install on the Mac . I'll take a look at correcting/
> >> simplifying
> >> rtt/FindTAO. I also have an omniorb install, so I'll make sure that
> >> doesn't break too.
> >>
> >>>> It also make me think that we should think about instituting
> >>>> automated
> >>>> daily builds ... might catch some of these earlier ...
> >>>
> >>> We have, but it runs on standard Debian, with standard Debian/
> >>> packages and
> >>> install locations.
> >>
> >> What are you using?
> >
> > My dev environment is Ubuntu 8.10 on AMD64. Our applications run on
> > Debian
> > etch (i386). I'm setting up a new test system for Lenny as well.
>
> What application are you using for the daily builds? CDash? Cruise
> Control? Custom home grown scripts ...?
Custom cron scripts that do a fresh checkout, configure, make all & check, make
install RTT and OCL. It reports success or failure by email. It reboots the PC
for gnulinux/lxrt/xenomai. Another machine does the automatic documentation
generation and pushes it to the web server.
Peter
Find TAO cmake broken
On Mar 4, 2009, at 07:15 , Peter Soetens wrote:
> On Tuesday 03 March 2009 21:56:58 Stephen Roderick wrote:
>> On Mar 3, 2009, at 10:38 , Peter Soetens wrote:
>>> On Tuesday 03 March 2009 13:52:16 Stephen Roderick wrote:
>>>> I've noticed that problem with orbsvcs. You think they could just
>>>> make
>>>> their mind up ...!
>>>>
>>>> I have here both a standard Ubuntu install, plus a non-standard
>>>> from
>>>> source install on the Mac . I'll take a look at correcting/
>>>> simplifying
>>>> rtt/FindTAO. I also have an omniorb install, so I'll make sure that
>>>> doesn't break too.
>>>>
>>>>>> It also make me think that we should think about instituting
>>>>>> automated
>>>>>> daily builds ... might catch some of these earlier ...
>>>>>
>>>>> We have, but it runs on standard Debian, with standard Debian/
>>>>> packages and
>>>>> install locations.
>>>>
>>>> What are you using?
>>>
>>> My dev environment is Ubuntu 8.10 on AMD64. Our applications run on
>>> Debian
>>> etch (i386). I'm setting up a new test system for Lenny as well.
>>
>> What application are you using for the daily builds? CDash? Cruise
>> Control? Custom home grown scripts ...?
>
> Custom cron scripts that do a fresh checkout, configure, make all &
> check, make
> install RTT and OCL. It reports success or failure by email. It
> reboots the PC
> for gnulinux/lxrt/xenomai. Another machine does the automatic
> documentation
> generation and pushes it to the web server.
Any thoughts on pushing this out to other configurations, perhaps by
using an OSS tool? Particularly as Orocos branches into new O/S's,
etc. Do you think the benefit would outweigh the pain?
S
Find TAO cmake broken
On Tue, Mar 3, 2009 at 2:30 AM, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
[...]
> It also make me think that we should think about instituting automated
> daily builds ... might catch some of these earlier ...
>
> Thoughts?
See <http://www.orocos.org/wiki/orocos/gsoc/bfl-ideas> idea 2. Maybe
we should present this idea as "orocos-wide", instead of just for BFL.
Klaas
Find TAO cmake broken. extra semicolons ;
I also had the problem with the semicolons. I solved it with the attached diff for src/corba/CMakeLists.txt
Find TAO cmake broken. extra semicolons ;
The patch is not complete because the generated orocos-rtt-corba-gnulinux.pc is still wrong (see bellow that Libs.private contains -I's and that both Libs.private & Cflags have some ; separators). This causes the compilation of OCL to fail. I didn't find where this is generated and don't provide a patch
Libs.private: -I/opt/boost/include -I/opt/xercesc/include;-L/opt/ACE_wrappers/lib;-L/dataServers/trac/tmp/Orocos/ACE_wrappers/TAO/lib;-L/dataServers/trac/tmp/Orocos/ACE_wrappers/TAO/include/orbsvcs/lib;-lTAO;-lTAO_PortableServer;-lTAO_CosNaming;-lACE
Cflags: -I/opt/boost/include -I/opt/xercesc/include;-I/opt/ACE_wrappers;-I/dataServers/trac/tmp/Orocos/ACE_wrappers/TAO;-I/dataServers/trac/tmp/Orocos/ACE_wrappers/TAO/include/orbsvcs -I${includedir}/rtt/corba
I also had the problem with the semicolons. I solved it with the attached diff for src/corba/CMakeLists.txt
Find TAO cmake broken. extra semicolons ;
";" is the list separator in cmake. It is usually generated when you use
"${A_LIST}"
where
${A_LIST} should be
(or the other way around actually, I'm not sure ... :P)
Find TAO cmake broken. extra semicolons ;
I think in the patch that I sent in that I added double quotes to one spot, which was the odd one out of a bunch that did have double quotes. I can't check from here right now, sorry.
S
On Wednesday, February 18, 2009, at 12:59PM, "Sylvain Joyeux" <sylvain [dot] joyeux [..] ...> wrote:
>";" is the list separator in cmake. It is usually generated when you use
>
> "${A_LIST}"
>
>where
> ${A_LIST} should be
>
>(or the other way around actually, I'm not sure ... :P)
Find TAO cmake broken
Nevermind, after a complete clean rebuild the problem disappeared.
Ruben
________________________________________
From: orocos-dev-bounces [..] ... [orocos-dev-bounces [..] ...] On Behalf Of Ruben Smits [Ruben [dot] Smits [..] ...]
Sent: Wednesday, February 18, 2009 14:19
To: orocos-dev [..] ...
Subject: Re: [Orocos-Dev] Find TAO cmake broken
It is due to the semi-colon (;) between the include flags, i do not know where is comes from.
Ruben
________________________________________
From: orocos-dev-bounces [..] ... [orocos-dev-bounces [..] ...] On Behalf Of Ruben Smits [Ruben [dot] Smits [..] ...]
Sent: Wednesday, February 18, 2009 14:13
To: orocos-dev [..] ...
Subject: Re: [Orocos-Dev] Find TAO cmake broken
I cannot build rtt-corba anymore since the latest patches:
[ 76%] Building CXX object src/corba/CMakeFiles/orocos-rtt-corba_dynamic-lxrt.dir/AttributesI.o
/usr/bin/c++ -DRTT_DLL_EXPORT -O2 -DNDEBUG -fPIC -I/usr/realtime/include -I/include -I/usr/local/src/rtt/src -I/usr/local/src/rtt/build-lxrt/src -I/usr/local/src/rtt/build-lxrt/src/os -I/usr/local/src/rtt/build-lxrt/src/os/lxrt -I/usr/include/orbsvcs -I/usr/local/src/rtt/build-lxrt/src/corba -Wall -I/usr/realtime/include -I/include -I/usr/realtime/include -I/include;-I/usr/include/orbsvcs -D_REENTRANT -DOROCOS_TARGET=lxrt -o src/corba/CMakeFiles/orocos-rtt-corba_dynamic-lxrt.dir/AttributesI.o -c /usr/local/src/rtt/src/corba/AttributesI.cpp
c++: no input files
/bin/sh: -I/usr/include/orbsvcs: not found
make[2]: *** [src/corba/CMakeFiles/orocos-rtt-corba_dynamic-lxrt.dir/AttributesI.o] Error 127
Ruben
________________________________________
From: orocos-dev-bounces [..] ... [orocos-dev-bounces [..] ...] On Behalf Of Peter Soetens [Peter [dot] Soetens [..] ...]
Sent: Wednesday, February 18, 2009 11:01
To: orocos-dev [..] ...; kiwi [dot] net [..] ...
Subject: Re: [Orocos-Dev] Find TAO cmake broken
On Tuesday 17 February 2009 20:28:53 kiwi [dot] net [..] ... wrote:
> Another patch for RTT, so can build deployer-corba.
Applied both patches. strange that I didn't catch these on my Ubuntu Intrepid
and Debian Etch(+testing) systems...
Peter
--
Peter Soetens -- FMTC -- <http://www.fmtc.be>
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm