Toolchain 2.3 status and release schedule

Submitted by peter on Fri, 2011-01-28 15:08

RTT-dev

I'd like to pull asap all branches people want in the 2.3 release. If
possible, I'd like to release the toolchain already next Friday, 4th of
February, or shortly after that date.

--RTT
There are two major changes on the RTT master branch: a new property
composition/decomposition system for marshalling to XML and the generation/use
of manifest.xml + .pc files for your UseOrocos.cmake based packages, for both
ROS and non-ROS setups. One of the advantages is that it will link with the
typekits of a package listed in the manifest.txt file. As such, you can include
its typekit/Types.hpp file and compilation time of your package will improve
significantly.

For the updated cmake logic, you'll need to add at the end of your
CMakeLists.txt file: orocos_generate_package() and you can remove the
configure_file()...upto...orocos_uninstall_target() statements found in
CMakefiles generated by the orocreate-pkg script.

There is some dead 'dotoperator' code I still need to remove from RTT. The
solution for installing a type alias when two C++ types are registered under a
different name is still pending as well.

--OCL
A major change for OCL, is that all libraries have been renamed to 'liborocos-
ocl-foo' instead of 'liborocos-foo' (except reporting which still must be
fixed). The headers have moved from prefix/include/ocl to
prefix/include/orocos/ocl. That's a lot of breakage we're having here in case
you extended OCL components or wrote custom deployers or apps. On the other
hand, all the .pc files are generated and updated with these new settings.

--log4cpp
I heard there were rumours for upgrading the build-system for log4cpp, if
someone is still interested in doing that, be my guest.

Peter

Toolchain 2.3 status and release schedule

Submitted by snrkiwi on Mon, 2011-01-31 01:28.

On Jan 28, 2011, at 10:02 , Peter Soetens wrote:

> I'd like to pull asap all branches people want in the 2.3 release. If
> possible, I'd like to release the toolchain already next Friday, 4th of
> February, or shortly after that date.
>
> --RTT
> There are two major changes on the RTT master branch: a new property
> composition/decomposition system for marshalling to XML and the generation/use
> of manifest.xml + .pc files for your UseOrocos.cmake based packages, for both
> ROS and non-ROS setups. One of the advantages is that it will link with the
> typekits of a package listed in the manifest.txt file. As such, you can include
> its typekit/Types.hpp file and compilation time of your package will improve
> significantly.
>
> For the updated cmake logic, you'll need to add at the end of your
> CMakeLists.txt file: orocos_generate_package() and you can remove the
> configure_file()...upto...orocos_uninstall_target() statements found in
> CMakefiles generated by the orocreate-pkg script.
>
> There is some dead 'dotoperator' code I still need to remove from RTT. The
> solution for installing a type alias when two C++ types are registered under a
> different name is still pending as well.
>
> --OCL
> A major change for OCL, is that all libraries have been renamed to 'liborocos-
> ocl-foo' instead of 'liborocos-foo' (except reporting which still must be
> fixed). The headers have moved from prefix/include/ocl to
> prefix/include/orocos/ocl. That's a lot of breakage we're having here in case
> you extended OCL components or wrote custom deployers or apps. On the other
> hand, all the .pc files are generated and updated with these new settings.
>
> --log4cpp
> I heard there were rumours for upgrading the build-system for log4cpp, if
> someone is still interested in doing that, be my guest.

Following request is branched from toolchain-2.2. I adapted Steven's ROS Makefile patch slightly. Tested on Lucid and Snow Leopard. I don't believe that this uses any of the autoconf results, but it's hard to tell. Tracking through their defines of defines is tough ...

The following changes since commit dc400d8dd2f6e7ea60730175b32311f263b89e1a:
Peter Soetens (1):
make: be more robust against erasion of build dir

are available in the git repository at:

http://git.gitorious.org/orocos-toolchain/log4cpp.git next

Stephen Roderick (4):
Add missing include file
Correct valid pointer check when setting category factory
cmake: Working CMake build of log4cpp
log4cpp: use cmake support

CMakeLists.txt | 121 +++++++++++++++++++++++++++++++++++++++++++
Makefile | 6 +-
include/config-cmake.h.in | 7 +++
src/HierarchyMaintainer.cpp | 3 +-
4 files changed, 133 insertions(+), 4 deletions(-)
create mode 100644 CMakeLists.txt
create mode 100644 include/config-cmake.h.in

Toolchain 2.3 status and release schedule

Submitted by peter on Mon, 2011-01-31 10:32.

On Monday 31 January 2011 02:26:24 S Roderick wrote:
> On Jan 28, 2011, at 10:02 , Peter Soetens wrote:
> > I'd like to pull asap all branches people want in the 2.3 release. If
> > possible, I'd like to release the toolchain already next Friday, 4th of
> > February, or shortly after that date.
> >
> > --RTT
> > There are two major changes on the RTT master branch: a new property
> > composition/decomposition system for marshalling to XML and the
> > generation/use of manifest.xml + .pc files for your UseOrocos.cmake
> > based packages, for both ROS and non-ROS setups. One of the advantages
> > is that it will link with the typekits of a package listed in the
> > manifest.txt file. As such, you can include its typekit/Types.hpp file
> > and compilation time of your package will improve significantly.
> >
> > For the updated cmake logic, you'll need to add at the end of your
> > CMakeLists.txt file: orocos_generate_package() and you can remove the
> > configure_file()...upto...orocos_uninstall_target() statements found in
> > CMakefiles generated by the orocreate-pkg script.
> >
> > There is some dead 'dotoperator' code I still need to remove from RTT.
> > The solution for installing a type alias when two C++ types are
> > registered under a different name is still pending as well.
> >
> > --OCL
> > A major change for OCL, is that all libraries have been renamed to
> > 'liborocos- ocl-foo' instead of 'liborocos-foo' (except reporting which
> > still must be fixed). The headers have moved from prefix/include/ocl to
> > prefix/include/orocos/ocl. That's a lot of breakage we're having here in
> > case you extended OCL components or wrote custom deployers or apps. On
> > the other hand, all the .pc files are generated and updated with these
> > new settings.
> >
> > --log4cpp
> > I heard there were rumours for upgrading the build-system for log4cpp, if
> > someone is still interested in doing that, be my guest.
>
> Following request is branched from toolchain-2.2. I adapted Steven's ROS
> Makefile patch slightly. Tested on Lucid and Snow Leopard. I don't believe
> that this uses any of the autoconf results, but it's hard to tell.
> Tracking through their defines of defines is tough ...

One of the things that's missing is the generation and installation of the .pc
file. We might need this in order to extract the cflags and ldflags
automatically.

For the rest, it builds/installs here/Ubuntu64 10.04.

Peter

Toolchain 2.3 status and release schedule

Submitted by snrkiwi on Sat, 2011-02-05 12:28.

On Jan 31, 2011, at 05:30 , Peter Soetens wrote:

> On Monday 31 January 2011 02:26:24 S Roderick wrote:
>> On Jan 28, 2011, at 10:02 , Peter Soetens wrote:
>>> I'd like to pull asap all branches people want in the 2.3 release. If
>>> possible, I'd like to release the toolchain already next Friday, 4th of
>>> February, or shortly after that date.
>>>
>>> --RTT
>>> There are two major changes on the RTT master branch: a new property
>>> composition/decomposition system for marshalling to XML and the
>>> generation/use of manifest.xml + .pc files for your UseOrocos.cmake
>>> based packages, for both ROS and non-ROS setups. One of the advantages
>>> is that it will link with the typekits of a package listed in the
>>> manifest.txt file. As such, you can include its typekit/Types.hpp file
>>> and compilation time of your package will improve significantly.
>>>
>>> For the updated cmake logic, you'll need to add at the end of your
>>> CMakeLists.txt file: orocos_generate_package() and you can remove the
>>> configure_file()...upto...orocos_uninstall_target() statements found in
>>> CMakefiles generated by the orocreate-pkg script.
>>>
>>> There is some dead 'dotoperator' code I still need to remove from RTT.
>>> The solution for installing a type alias when two C++ types are
>>> registered under a different name is still pending as well.
>>>
>>> --OCL
>>> A major change for OCL, is that all libraries have been renamed to
>>> 'liborocos- ocl-foo' instead of 'liborocos-foo' (except reporting which
>>> still must be fixed). The headers have moved from prefix/include/ocl to
>>> prefix/include/orocos/ocl. That's a lot of breakage we're having here in
>>> case you extended OCL components or wrote custom deployers or apps. On
>>> the other hand, all the .pc files are generated and updated with these
>>> new settings.
>>>
>>> --log4cpp
>>> I heard there were rumours for upgrading the build-system for log4cpp, if
>>> someone is still interested in doing that, be my guest.
>>
>> Following request is branched from toolchain-2.2. I adapted Steven's ROS
>> Makefile patch slightly. Tested on Lucid and Snow Leopard. I don't believe
>> that this uses any of the autoconf results, but it's hard to tell.
>> Tracking through their defines of defines is tough ...
>
> One of the things that's missing is the generation and installation of the .pc
> file. We might need this in order to extract the cflags and ldflags
> automatically.

Please try log4cpp/next branch now.
S

Toolchain 2.3 status and release schedule

Submitted by peter on Tue, 2011-02-08 10:08.

On Saturday 05 February 2011 13:26:46 Stephen Roderick wrote:
> On Jan 31, 2011, at 05:30 , Peter Soetens wrote:
> > On Monday 31 January 2011 02:26:24 S Roderick wrote:
> >> On Jan 28, 2011, at 10:02 , Peter Soetens wrote:
> >>> I'd like to pull asap all branches people want in the 2.3 release. If
> >>> possible, I'd like to release the toolchain already next Friday, 4th of
> >>> February, or shortly after that date.
> >>>
> >>> --RTT
> >>> There are two major changes on the RTT master branch: a new property
> >>> composition/decomposition system for marshalling to XML and the
> >>> generation/use of manifest.xml + .pc files for your UseOrocos.cmake
> >>> based packages, for both ROS and non-ROS setups. One of the advantages
> >>> is that it will link with the typekits of a package listed in the
> >>> manifest.txt file. As such, you can include its typekit/Types.hpp file
> >>> and compilation time of your package will improve significantly.
> >>>
> >>> For the updated cmake logic, you'll need to add at the end of your
> >>> CMakeLists.txt file: orocos_generate_package() and you can remove the
> >>> configure_file()...upto...orocos_uninstall_target() statements found in
> >>> CMakefiles generated by the orocreate-pkg script.
> >>>
> >>> There is some dead 'dotoperator' code I still need to remove from RTT.
> >>> The solution for installing a type alias when two C++ types are
> >>> registered under a different name is still pending as well.
> >>>
> >>> --OCL
> >>> A major change for OCL, is that all libraries have been renamed to
> >>> 'liborocos- ocl-foo' instead of 'liborocos-foo' (except reporting which
> >>> still must be fixed). The headers have moved from prefix/include/ocl to
> >>> prefix/include/orocos/ocl. That's a lot of breakage we're having here
> >>> in case you extended OCL components or wrote custom deployers or apps.
> >>> On the other hand, all the .pc files are generated and updated with
> >>> these new settings.
> >>>
> >>> --log4cpp
> >>> I heard there were rumours for upgrading the build-system for log4cpp,
> >>> if someone is still interested in doing that, be my guest.
> >>
> >> Following request is branched from toolchain-2.2. I adapted Steven's ROS
> >> Makefile patch slightly. Tested on Lucid and Snow Leopard. I don't
> >> believe that this uses any of the autoconf results, but it's hard to
> >> tell. Tracking through their defines of defines is tough ...
> >
> > One of the things that's missing is the generation and installation of
> > the .pc file. We might need this in order to extract the cflags and
> > ldflags automatically.
>
> Please try log4cpp/next branch now.

Thanks. I'll further patch your .pc logic. It shouldn't contain the -O2/NDEBUG
flags. The .pc file does not tell the user with which flags log4cpp is compiled,
but with which flags the user should compile/link when including a log4cpp
header. Typically, this is including the include path and linking with the
library. So your patch included too much information.

Peter

Toolchain 2.3 status and release schedule

Submitted by peter on Tue, 2011-02-08 10:20.

On Tuesday 08 February 2011 11:06:09 Peter Soetens wrote:
> On Saturday 05 February 2011 13:26:46 Stephen Roderick wrote:
> > On Jan 31, 2011, at 05:30 , Peter Soetens wrote:
> > > On Monday 31 January 2011 02:26:24 S Roderick wrote:
> > >> On Jan 28, 2011, at 10:02 , Peter Soetens wrote:
> > >>> I'd like to pull asap all branches people want in the 2.3 release. If
> > >>> possible, I'd like to release the toolchain already next Friday, 4th
> > >>> of February, or shortly after that date.
> > >>>
> > >>> --RTT
> > >>> There are two major changes on the RTT master branch: a new property
> > >>> composition/decomposition system for marshalling to XML and the
> > >>> generation/use of manifest.xml + .pc files for your UseOrocos.cmake
> > >>> based packages, for both ROS and non-ROS setups. One of the
> > >>> advantages is that it will link with the typekits of a package
> > >>> listed in the manifest.txt file. As such, you can include its
> > >>> typekit/Types.hpp file and compilation time of your package will
> > >>> improve significantly.
> > >>>
> > >>> For the updated cmake logic, you'll need to add at the end of your
> > >>> CMakeLists.txt file: orocos_generate_package() and you can remove the
> > >>> configure_file()...upto...orocos_uninstall_target() statements found
> > >>> in CMakefiles generated by the orocreate-pkg script.
> > >>>
> > >>> There is some dead 'dotoperator' code I still need to remove from
> > >>> RTT. The solution for installing a type alias when two C++ types are
> > >>> registered under a different name is still pending as well.
> > >>>
> > >>> --OCL
> > >>> A major change for OCL, is that all libraries have been renamed to
> > >>> 'liborocos- ocl-foo' instead of 'liborocos-foo' (except reporting
> > >>> which still must be fixed). The headers have moved from
> > >>> prefix/include/ocl to prefix/include/orocos/ocl. That's a lot of
> > >>> breakage we're having here in case you extended OCL components or
> > >>> wrote custom deployers or apps. On the other hand, all the .pc files
> > >>> are generated and updated with these new settings.
> > >>>
> > >>> --log4cpp
> > >>> I heard there were rumours for upgrading the build-system for
> > >>> log4cpp, if someone is still interested in doing that, be my guest.
> > >>
> > >> Following request is branched from toolchain-2.2. I adapted Steven's
> > >> ROS Makefile patch slightly. Tested on Lucid and Snow Leopard. I
> > >> don't believe that this uses any of the autoconf results, but it's
> > >> hard to tell. Tracking through their defines of defines is tough ...
> > >
> > > One of the things that's missing is the generation and installation of
> > > the .pc file. We might need this in order to extract the cflags and
> > > ldflags automatically.
> >
> > Please try log4cpp/next branch now.
>
> Thanks. I'll further patch your .pc logic. It shouldn't contain the
> -O2/NDEBUG flags. The .pc file does not tell the user with which flags
> log4cpp is compiled, but with which flags the user should compile/link
> when including a log4cpp header. Typically, this is including the include
> path and linking with the library. So your patch included too much
> information.

I also removed the -pthread flag from the cflags in the .pc file. Does client
code on Apple require this flag ?

Peter

Toolchain 2.3 status and release schedule

Submitted by snrkiwi on Tue, 2011-02-08 21:00.

On Feb 8, 2011, at 05:18 , Peter Soetens wrote:

> On Tuesday 08 February 2011 11:06:09 Peter Soetens wrote:
>> On Saturday 05 February 2011 13:26:46 Stephen Roderick wrote:
>>> On Jan 31, 2011, at 05:30 , Peter Soetens wrote:
>>>> On Monday 31 January 2011 02:26:24 S Roderick wrote:
>>>>> On Jan 28, 2011, at 10:02 , Peter Soetens wrote:
>>>>>> I'd like to pull asap all branches people want in the 2.3 release. If
>>>>>> possible, I'd like to release the toolchain already next Friday, 4th
>>>>>> of February, or shortly after that date.
>>>>>>
>>>>>> --RTT
>>>>>> There are two major changes on the RTT master branch: a new property
>>>>>> composition/decomposition system for marshalling to XML and the
>>>>>> generation/use of manifest.xml + .pc files for your UseOrocos.cmake
>>>>>> based packages, for both ROS and non-ROS setups. One of the
>>>>>> advantages is that it will link with the typekits of a package
>>>>>> listed in the manifest.txt file. As such, you can include its
>>>>>> typekit/Types.hpp file and compilation time of your package will
>>>>>> improve significantly.
>>>>>>
>>>>>> For the updated cmake logic, you'll need to add at the end of your
>>>>>> CMakeLists.txt file: orocos_generate_package() and you can remove the
>>>>>> configure_file()...upto...orocos_uninstall_target() statements found
>>>>>> in CMakefiles generated by the orocreate-pkg script.
>>>>>>
>>>>>> There is some dead 'dotoperator' code I still need to remove from
>>>>>> RTT. The solution for installing a type alias when two C++ types are
>>>>>> registered under a different name is still pending as well.
>>>>>>
>>>>>> --OCL
>>>>>> A major change for OCL, is that all libraries have been renamed to
>>>>>> 'liborocos- ocl-foo' instead of 'liborocos-foo' (except reporting
>>>>>> which still must be fixed). The headers have moved from
>>>>>> prefix/include/ocl to prefix/include/orocos/ocl. That's a lot of
>>>>>> breakage we're having here in case you extended OCL components or
>>>>>> wrote custom deployers or apps. On the other hand, all the .pc files
>>>>>> are generated and updated with these new settings.
>>>>>>
>>>>>> --log4cpp
>>>>>> I heard there were rumours for upgrading the build-system for
>>>>>> log4cpp, if someone is still interested in doing that, be my guest.
>>>>>
>>>>> Following request is branched from toolchain-2.2. I adapted Steven's
>>>>> ROS Makefile patch slightly. Tested on Lucid and Snow Leopard. I
>>>>> don't believe that this uses any of the autoconf results, but it's
>>>>> hard to tell. Tracking through their defines of defines is tough ...
>>>>
>>>> One of the things that's missing is the generation and installation of
>>>> the .pc file. We might need this in order to extract the cflags and
>>>> ldflags automatically.
>>>
>>> Please try log4cpp/next branch now.
>>
>> Thanks. I'll further patch your .pc logic. It shouldn't contain the
>> -O2/NDEBUG flags. The .pc file does not tell the user with which flags
>> log4cpp is compiled, but with which flags the user should compile/link
>> when including a log4cpp header. Typically, this is including the include
>> path and linking with the library. So your patch included too much
>> information.
>
> I also removed the -pthread flag from the cflags in the .pc file. Does client
> code on Apple require this flag ?
>
> Peter

If you can, please hold off on releasing the CMake build of log4cpp. I've run into some issues that need resolution first.

Sorry
S

Toolchain 2.3 status and release schedule

Submitted by snrkiwi on Wed, 2011-02-09 02:00.

On Feb 8, 2011, at 15:59 , Stephen Roderick wrote:

> On Feb 8, 2011, at 05:18 , Peter Soetens wrote:
>
>> On Tuesday 08 February 2011 11:06:09 Peter Soetens wrote:
>>> On Saturday 05 February 2011 13:26:46 Stephen Roderick wrote:
>>>> On Jan 31, 2011, at 05:30 , Peter Soetens wrote:
>>>>> On Monday 31 January 2011 02:26:24 S Roderick wrote:
>>>>>> On Jan 28, 2011, at 10:02 , Peter Soetens wrote:
>>>>>>> I'd like to pull asap all branches people want in the 2.3 release. If
>>>>>>> possible, I'd like to release the toolchain already next Friday, 4th
>>>>>>> of February, or shortly after that date.
>>>>>>>
>>>>>>> --RTT
>>>>>>> There are two major changes on the RTT master branch: a new property
>>>>>>> composition/decomposition system for marshalling to XML and the
>>>>>>> generation/use of manifest.xml + .pc files for your UseOrocos.cmake
>>>>>>> based packages, for both ROS and non-ROS setups. One of the
>>>>>>> advantages is that it will link with the typekits of a package
>>>>>>> listed in the manifest.txt file. As such, you can include its
>>>>>>> typekit/Types.hpp file and compilation time of your package will
>>>>>>> improve significantly.
>>>>>>>
>>>>>>> For the updated cmake logic, you'll need to add at the end of your
>>>>>>> CMakeLists.txt file: orocos_generate_package() and you can remove the
>>>>>>> configure_file()...upto...orocos_uninstall_target() statements found
>>>>>>> in CMakefiles generated by the orocreate-pkg script.
>>>>>>>
>>>>>>> There is some dead 'dotoperator' code I still need to remove from
>>>>>>> RTT. The solution for installing a type alias when two C++ types are
>>>>>>> registered under a different name is still pending as well.
>>>>>>>
>>>>>>> --OCL
>>>>>>> A major change for OCL, is that all libraries have been renamed to
>>>>>>> 'liborocos- ocl-foo' instead of 'liborocos-foo' (except reporting
>>>>>>> which still must be fixed). The headers have moved from
>>>>>>> prefix/include/ocl to prefix/include/orocos/ocl. That's a lot of
>>>>>>> breakage we're having here in case you extended OCL components or
>>>>>>> wrote custom deployers or apps. On the other hand, all the .pc files
>>>>>>> are generated and updated with these new settings.
>>>>>>>
>>>>>>> --log4cpp
>>>>>>> I heard there were rumours for upgrading the build-system for
>>>>>>> log4cpp, if someone is still interested in doing that, be my guest.
>>>>>>
>>>>>> Following request is branched from toolchain-2.2. I adapted Steven's
>>>>>> ROS Makefile patch slightly. Tested on Lucid and Snow Leopard. I
>>>>>> don't believe that this uses any of the autoconf results, but it's
>>>>>> hard to tell. Tracking through their defines of defines is tough ...
>>>>>
>>>>> One of the things that's missing is the generation and installation of
>>>>> the .pc file. We might need this in order to extract the cflags and
>>>>> ldflags automatically.
>>>>
>>>> Please try log4cpp/next branch now.
>>>
>>> Thanks. I'll further patch your .pc logic. It shouldn't contain the
>>> -O2/NDEBUG flags. The .pc file does not tell the user with which flags
>>> log4cpp is compiled, but with which flags the user should compile/link
>>> when including a log4cpp header. Typically, this is including the include
>>> path and linking with the library. So your patch included too much
>>> information.
>>
>> I also removed the -pthread flag from the cflags in the .pc file. Does client
>> code on Apple require this flag ?
>>
>> Peter
>
> If you can, please hold off on releasing the CMake build of log4cpp. I've run into some issues that need resolution first.
>
> Sorry
> S

I believe that it is fixed. There is a nasty littley bug in the existing CMake generation that prevents use of millisecond data in timestamps (they come out all zero).

I have added a patch to do CMake-style configure for nearly all of the LOG4CPP_HAVE_xxx defines that they conditionally compile on. The ones that I have chosen not to do are either used only by tests, appear to have little to nor effect, or are simply something we are unlikely to use in Orocos (eg threading). The other patch standardizes their conditional compilation so that it works.

I have tested this briefly in our development system, on both 10.04 Lucid and Snow Leopard, and all appears fine.

I've updated the log4cpp/next branch. Let me know if you have any issues.
S

Toolchain 2.3 status and release schedule

Submitted by peter on Wed, 2011-02-09 08:24.

On Wednesday 09 February 2011 02:59:29 S Roderick wrote:
> On Feb 8, 2011, at 15:59 , Stephen Roderick wrote:
> > On Feb 8, 2011, at 05:18 , Peter Soetens wrote:
> >> On Tuesday 08 February 2011 11:06:09 Peter Soetens wrote:
> >>> On Saturday 05 February 2011 13:26:46 Stephen Roderick wrote:
> >>>> On Jan 31, 2011, at 05:30 , Peter Soetens wrote:
> >>>>> On Monday 31 January 2011 02:26:24 S Roderick wrote:
> >>>>>> On Jan 28, 2011, at 10:02 , Peter Soetens wrote:
> >>>>>>> I'd like to pull asap all branches people want in the 2.3 release.
> >>>>>>> If possible, I'd like to release the toolchain already next
> >>>>>>> Friday, 4th of February, or shortly after that date.
> >>>>>>>
> >>>>>>> --RTT
> >>>>>>> There are two major changes on the RTT master branch: a new
> >>>>>>> property composition/decomposition system for marshalling to XML
> >>>>>>> and the generation/use of manifest.xml + .pc files for your
> >>>>>>> UseOrocos.cmake based packages, for both ROS and non-ROS setups.
> >>>>>>> One of the advantages is that it will link with the typekits of a
> >>>>>>> package listed in the manifest.txt file. As such, you can include
> >>>>>>> its typekit/Types.hpp file and compilation time of your package
> >>>>>>> will improve significantly.
> >>>>>>>
> >>>>>>> For the updated cmake logic, you'll need to add at the end of your
> >>>>>>> CMakeLists.txt file: orocos_generate_package() and you can remove
> >>>>>>> the configure_file()...upto...orocos_uninstall_target() statements
> >>>>>>> found in CMakefiles generated by the orocreate-pkg script.
> >>>>>>>
> >>>>>>> There is some dead 'dotoperator' code I still need to remove from
> >>>>>>> RTT. The solution for installing a type alias when two C++ types
> >>>>>>> are registered under a different name is still pending as well.
> >>>>>>>
> >>>>>>> --OCL
> >>>>>>> A major change for OCL, is that all libraries have been renamed to
> >>>>>>> 'liborocos- ocl-foo' instead of 'liborocos-foo' (except reporting
> >>>>>>> which still must be fixed). The headers have moved from
> >>>>>>> prefix/include/ocl to prefix/include/orocos/ocl. That's a lot of
> >>>>>>> breakage we're having here in case you extended OCL components or
> >>>>>>> wrote custom deployers or apps. On the other hand, all the .pc
> >>>>>>> files are generated and updated with these new settings.
> >>>>>>>
> >>>>>>> --log4cpp
> >>>>>>> I heard there were rumours for upgrading the build-system for
> >>>>>>> log4cpp, if someone is still interested in doing that, be my guest.
> >>>>>>
> >>>>>> Following request is branched from toolchain-2.2. I adapted Steven's
> >>>>>> ROS Makefile patch slightly. Tested on Lucid and Snow Leopard. I
> >>>>>> don't believe that this uses any of the autoconf results, but it's
> >>>>>> hard to tell. Tracking through their defines of defines is tough ...
> >>>>>
> >>>>> One of the things that's missing is the generation and installation
> >>>>> of the .pc file. We might need this in order to extract the cflags
> >>>>> and ldflags automatically.
> >>>>
> >>>> Please try log4cpp/next branch now.
> >>>
> >>> Thanks. I'll further patch your .pc logic. It shouldn't contain the
> >>> -O2/NDEBUG flags. The .pc file does not tell the user with which flags
> >>> log4cpp is compiled, but with which flags the user should compile/link
> >>> when including a log4cpp header. Typically, this is including the
> >>> include path and linking with the library. So your patch included too
> >>> much information.
> >>
> >> I also removed the -pthread flag from the cflags in the .pc file. Does
> >> client code on Apple require this flag ?
> >>
> >> Peter
> >
> > If you can, please hold off on releasing the CMake build of log4cpp. I've
> > run into some issues that need resolution first.
> >
> > Sorry
> > S
>
> I believe that it is fixed. There is a nasty littley bug in the existing
> CMake generation that prevents use of millisecond data in timestamps (they
> come out all zero).
>
> I have added a patch to do CMake-style configure for nearly all of the
> LOG4CPP_HAVE_xxx defines that they conditionally compile on. The ones that
> I have chosen not to do are either used only by tests, appear to have
> little to nor effect, or are simply something we are unlikely to use in
> Orocos (eg threading). The other patch standardizes their conditional
> compilation so that it works.
>
> I have tested this briefly in our development system, on both 10.04 Lucid
> and Snow Leopard, and all appears fine.
>
> I've updated the log4cpp/next branch. Let me know if you have any issues.

Thanks,

I'll merge it asap.

Peter

Toolchain 2.3 status and release schedule

Submitted by snrkiwi on Tue, 2011-02-08 12:00.

On Feb 8, 2011, at 05:18 , Peter Soetens wrote:

No. I pretty much tried to follow what was already in log4cpp. I'm not as familiar with .pc requirements, so thanks for cleaning up.
S

Toolchain 2.3 status and release schedule

Submitted by snrkiwi on Thu, 2011-02-03 12:24.

On Jan 31, 2011, at 05:30 , Peter Soetens wrote:

Will fix this soon, but not sure I'll get it to you before tomorrow ... I'm swamped right now ...

> For the rest, it builds/installs here/Ubuntu64 10.04.