Hello,
I'm trying to clean up a bit the win32 port of orocos for the next release
and I'm not sure what can I disable by default on windows. It's pretty clear
for RTT, but not that much for OCL. I have these CMake variables/options:
BUILD_RTALLOC
BUILD_LOGGING
LOG4CPP_FOUND
BUILD_LOGGING depends on LOG4CPP_FOUND, but what about
BUILD_RTALLOC? BUILD_RTALLOC is forced to off on win32, so should
BUILD_LOGGING be forced to off too?
Philippe
BUILD_RTALLOC, BUILD_LOGGING, etc.
On Tuesday 08 February 2011 16:56:43 Philippe Hamelin wrote:
> Hello,
>
> I'm trying to clean up a bit the win32 port of orocos for the next release
> and I'm not sure what can I disable by default on windows. It's pretty
> clear for RTT, but not that much for OCL. I have these CMake
> variables/options:
>
> BUILD_RTALLOC
> BUILD_LOGGING
> LOG4CPP_FOUND
>
> BUILD_LOGGING depends on LOG4CPP_FOUND, but what about
> BUILD_RTALLOC? BUILD_RTALLOC is forced to off on win32, so should
> BUILD_LOGGING be forced to off too?
I don't want this, *if* we can build log4cpp on Windows, we should be able to
use it, but then without the RTALLOC extensions and using the traditional
malloc. That said, only BUILD_LOGGING depends on the rt-alloc functionality.
BUILD_RTALLOC should only be on if RTT was built with OS_RT_MALLOC turned on.
Afaikt, the CMake port of Stephen should at least allow to create a MSVC
project out of it. I don't know if it would actually build.
The easiest way out is to disable BUILD_LOGGING and BUILD_RTALLOC on Win32
until someone verified it can work. Since we're leaning towards replacing all
logging with the log4cpp implementation, Win32 support is kind-of a high
priority though.
Peter
BUILD_RTALLOC, BUILD_LOGGING, etc.
On Feb 10, 2011, at 06:12 , Peter Soetens wrote:
> On Tuesday 08 February 2011 16:56:43 Philippe Hamelin wrote:
>> Hello,
>>
>> I'm trying to clean up a bit the win32 port of orocos for the next release
>> and I'm not sure what can I disable by default on windows. It's pretty
>> clear for RTT, but not that much for OCL. I have these CMake
>> variables/options:
>>
>> BUILD_RTALLOC
>> BUILD_LOGGING
>> LOG4CPP_FOUND
>>
>> BUILD_LOGGING depends on LOG4CPP_FOUND, but what about
>> BUILD_RTALLOC? BUILD_RTALLOC is forced to off on win32, so should
>> BUILD_LOGGING be forced to off too?
>
> I don't want this, *if* we can build log4cpp on Windows, we should be able to
> use it, but then without the RTALLOC extensions and using the traditional
> malloc. That said, only BUILD_LOGGING depends on the rt-alloc functionality.
> BUILD_RTALLOC should only be on if RTT was built with OS_RT_MALLOC turned on.
I believe that log4cpp can natively be built on Windows. I don't think our extensions make a difference, as all our log4cpp patches did was support use of a factory for creation of log4cpp categories. And the actual factory is in the ocl/logging implementation.
Having said that, the TLSF implementation is pretty portable and might be useable (in non-realtime, same as on a Mac) on Windows. Perhaps omeone should try building this, just make sure SBRK and MMAP are off.
So are the proposed dependancies ...?
LOG4CPP_FOUND iff an installed version of log4cpp is found.
BUILD_RTALLOC iff OS_RT_MALLOC was turned on within RTT
BUILD_LOGGING iff LOG4CPP_FOUND && BUILD_RTALLOC==ON
If OS_RT_MALLOC was off, a user can still use an installed log4cpp just without our real-time extensions.
> Afaikt, the CMake port of Stephen should at least allow to create a MSVC
> project out of it. I don't know if it would actually build.
I presume so. I've no way to test this.
> The easiest way out is to disable BUILD_LOGGING and BUILD_RTALLOC on Win32
> until someone verified it can work. Since we're leaning towards replacing all
> logging with the log4cpp implementation, Win32 support is kind-of a high
> priority though.
+1 and +1.
Is someone willing to test log4cpp updates on Windows?
S
BUILD_RTALLOC, BUILD_LOGGING, etc.
2011/2/10 S Roderick <kiwi [dot] net [..] ...>
> On Feb 10, 2011, at 06:12 , Peter Soetens wrote:
>
> > On Tuesday 08 February 2011 16:56:43 Philippe Hamelin wrote:
> >> Hello,
> >>
> >> I'm trying to clean up a bit the win32 port of orocos for the next
> release
> >> and I'm not sure what can I disable by default on windows. It's pretty
> >> clear for RTT, but not that much for OCL. I have these CMake
> >> variables/options:
> >>
> >> BUILD_RTALLOC
> >> BUILD_LOGGING
> >> LOG4CPP_FOUND
> >>
> >> BUILD_LOGGING depends on LOG4CPP_FOUND, but what about
> >> BUILD_RTALLOC? BUILD_RTALLOC is forced to off on win32, so should
> >> BUILD_LOGGING be forced to off too?
> >
> > I don't want this, *if* we can build log4cpp on Windows, we should be
> able to
> > use it, but then without the RTALLOC extensions and using the traditional
> > malloc. That said, only BUILD_LOGGING depends on the rt-alloc
> functionality.
> > BUILD_RTALLOC should only be on if RTT was built with OS_RT_MALLOC turned
> on.
>
> I believe that log4cpp can natively be built on Windows. I don't think our
> extensions make a difference, as all our log4cpp patches did was support use
> of a factory for creation of log4cpp categories. And the actual factory is
> in the ocl/logging implementation.
>
> Having said that, the TLSF implementation is pretty portable and might be
> useable (in non-realtime, same as on a Mac) on Windows. Perhaps omeone
> should try building this, just make sure SBRK and MMAP are off.
>
> So are the proposed dependancies ...?
>
> LOG4CPP_FOUND iff an installed version of log4cpp is found.
> BUILD_RTALLOC iff OS_RT_MALLOC was turned on within RTT
> BUILD_LOGGING iff LOG4CPP_FOUND && BUILD_RTALLOC==ON
>
> If OS_RT_MALLOC was off, a user can still use an installed log4cpp just
> without our real-time extensions.
>
> > Afaikt, the CMake port of Stephen should at least allow to create a MSVC
> > project out of it. I don't know if it would actually build.
>
> I presume so. I've no way to test this.
>
> > The easiest way out is to disable BUILD_LOGGING and BUILD_RTALLOC on
> Win32
> > until someone verified it can work. Since we're leaning towards replacing
> all
> > logging with the log4cpp implementation, Win32 support is kind-of a high
> > priority though.
>
> +1 and +1.
>
> Is someone willing to test log4cpp updates on Windows?
>
Our unit tests ran successfuly on win32 with the log4cpp master branch. We
only tested bare log4cpp, not the integration with orocos (e.g. logging
service).
Philippe
BUILD_RTALLOC, BUILD_LOGGING, etc.
2011/2/10 S Roderick <kiwi [dot] net [..] ...>
> On Feb 10, 2011, at 06:12 , Peter Soetens wrote:
>
> > On Tuesday 08 February 2011 16:56:43 Philippe Hamelin wrote:
> >> Hello,
> >>
> >> I'm trying to clean up a bit the win32 port of orocos for the next
> release
> >> and I'm not sure what can I disable by default on windows. It's pretty
> >> clear for RTT, but not that much for OCL. I have these CMake
> >> variables/options:
> >>
> >> BUILD_RTALLOC
> >> BUILD_LOGGING
> >> LOG4CPP_FOUND
> >>
> >> BUILD_LOGGING depends on LOG4CPP_FOUND, but what about
> >> BUILD_RTALLOC? BUILD_RTALLOC is forced to off on win32, so should
> >> BUILD_LOGGING be forced to off too?
> >
> > I don't want this, *if* we can build log4cpp on Windows, we should be
> able to
> > use it, but then without the RTALLOC extensions and using the traditional
> > malloc. That said, only BUILD_LOGGING depends on the rt-alloc
> functionality.
> > BUILD_RTALLOC should only be on if RTT was built with OS_RT_MALLOC turned
> on.
>
> I believe that log4cpp can natively be built on Windows. I don't think our
> extensions make a difference, as all our log4cpp patches did was support use
> of a factory for creation of log4cpp categories. And the actual factory is
> in the ocl/logging implementation.
>
> Having said that, the TLSF implementation is pretty portable and might be
> useable (in non-realtime, same as on a Mac) on Windows. Perhaps omeone
> should try building this, just make sure SBRK and MMAP are off.
>
> So are the proposed dependancies ...?
>
> LOG4CPP_FOUND iff an installed version of log4cpp is found.
> BUILD_RTALLOC iff OS_RT_MALLOC was turned on within RTT
> BUILD_LOGGING iff LOG4CPP_FOUND && BUILD_RTALLOC==ON
>
> If OS_RT_MALLOC was off, a user can still use an installed log4cpp just
> without our real-time extensions.
>
> > Afaikt, the CMake port of Stephen should at least allow to create a MSVC
> > project out of it. I don't know if it would actually build.
>
> I presume so. I've no way to test this.
>
> > The easiest way out is to disable BUILD_LOGGING and BUILD_RTALLOC on
> Win32
> > until someone verified it can work. Since we're leaning towards replacing
> all
> > logging with the log4cpp implementation, Win32 support is kind-of a high
> > priority though.
>
> +1 and +1.
>
> Is someone willing to test log4cpp updates on Windows?
>
Log4cpp should already build with the cmake patch that I submitted to you.
I'm quite busy in fixing orocos-win32 now, but I will make an effort to run
a quick test with log4cpp on MSVC. We already have a unit test for that on
Linux so it should be quick straightforward.
Philippe
BUILD_RTALLOC, BUILD_LOGGING, etc.
On Thursday 10 February 2011 14:39:29 Philippe Hamelin wrote:
> 2011/2/10 S Roderick <kiwi [dot] net [..] ...>
>
> > On Feb 10, 2011, at 06:12 , Peter Soetens wrote:
> > > On Tuesday 08 February 2011 16:56:43 Philippe Hamelin wrote:
> > >> Hello,
> > >>
> > >> I'm trying to clean up a bit the win32 port of orocos for the next
> >
> > release
> >
> > >> and I'm not sure what can I disable by default on windows. It's pretty
> > >> clear for RTT, but not that much for OCL. I have these CMake
> > >> variables/options:
> > >>
> > >> BUILD_RTALLOC
> > >> BUILD_LOGGING
> > >> LOG4CPP_FOUND
> > >>
> > >> BUILD_LOGGING depends on LOG4CPP_FOUND, but what about
> > >> BUILD_RTALLOC? BUILD_RTALLOC is forced to off on win32, so should
> > >> BUILD_LOGGING be forced to off too?
> > >
> > > I don't want this, *if* we can build log4cpp on Windows, we should be
> >
> > able to
> >
> > > use it, but then without the RTALLOC extensions and using the
> > > traditional malloc. That said, only BUILD_LOGGING depends on the
> > > rt-alloc
> >
> > functionality.
> >
> > > BUILD_RTALLOC should only be on if RTT was built with OS_RT_MALLOC
> > > turned
> >
> > on.
> >
> > I believe that log4cpp can natively be built on Windows. I don't think
> > our extensions make a difference, as all our log4cpp patches did was
> > support use of a factory for creation of log4cpp categories. And the
> > actual factory is in the ocl/logging implementation.
> >
> > Having said that, the TLSF implementation is pretty portable and might be
> > useable (in non-realtime, same as on a Mac) on Windows. Perhaps omeone
> > should try building this, just make sure SBRK and MMAP are off.
> >
> > So are the proposed dependancies ...?
> >
> > LOG4CPP_FOUND iff an installed version of log4cpp is found.
> > BUILD_RTALLOC iff OS_RT_MALLOC was turned on within RTT
> > BUILD_LOGGING iff LOG4CPP_FOUND && BUILD_RTALLOC==ON
> >
> > If OS_RT_MALLOC was off, a user can still use an installed log4cpp just
> > without our real-time extensions.
> >
> > > Afaikt, the CMake port of Stephen should at least allow to create a
> > > MSVC project out of it. I don't know if it would actually build.
> >
> > I presume so. I've no way to test this.
> >
> > > The easiest way out is to disable BUILD_LOGGING and BUILD_RTALLOC on
> >
> > Win32
> >
> > > until someone verified it can work. Since we're leaning towards
> > > replacing
> >
> > all
> >
> > > logging with the log4cpp implementation, Win32 support is kind-of a
> > > high priority though.
> >
> > +1 and +1.
> >
> > Is someone willing to test log4cpp updates on Windows?
>
> Log4cpp should already build with the cmake patch that I submitted to you.
> I'm quite busy in fixing orocos-win32 now, but I will make an effort to run
> a quick test with log4cpp on MSVC. We already have a unit test for that on
> Linux so it should be quick straightforward.
Please keep me in the loop for the rtt-win32 problems. Maybe we should connect
on irc ?
Peter
BUILD_RTALLOC, BUILD_LOGGING, etc.
On Feb 8, 2011, at 10:56 , Philippe Hamelin wrote:
> Hello,
>
> I'm trying to clean up a bit the win32 port of orocos for the next release and I'm not sure what can I disable by default on windows. It's pretty clear for RTT, but not that much for OCL. I have these CMake variables/options:
>
> BUILD_RTALLOC
> BUILD_LOGGING
> LOG4CPP_FOUND
>
> BUILD_LOGGING depends on LOG4CPP_FOUND, but what about BUILD_RTALLOC? BUILD_RTALLOC is forced to off on win32, so should BUILD_LOGGING be forced to off too?
Logging requires TLSF and the Orocos real-time string that uses it, but if this is v2 then the rt_string that was in OCL has been moved to RTT so I think the BUILD_RTALLOC is now obsolete.
We're not using v2, so I don't know exactly.
S