> -----Original Message-----
> From: S Roderick [mailto:kiwi [dot] net [..] ...]
> Sent: 5. februar 2009 21:22
> To: Jimmy Alison Jørgensen
> Cc: orocos-dev [..] ...
> Subject: Re: [Orocos-Dev] [Bug 605] Initial RTT port for Windows/cygwin
>
> On Feb 2, 2009, at 06:08 , Jimmy Jorgensen wrote:
>
> > For more infomation about this bug, visit
> <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=605
> > >
> >
> >
> >
> > --- Comment #4 from Jimmy Jorgensen <jimali [..] ...> 2009-02-02
> > 12:08:57 ---
> > Created an attachment (id=380)
> > --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=380)
> > MinGW32 support for orocos-rtt
> >
> > * it is based solely on mingw32, no msys or cygwin.
> > * it use native windows threads. No need for pthreads.
> > * only ports RTT, and currently without support for Corba
> > * it uses the fixes that Peter made regarding 'weak' symbol handling.
> > * 4 out of 8 tests work. (ported CPPUnit to BOOST tests since
> > CPPUnit requires
> > the obnoxious automake )
> > * Priorities are supported on thread level, though creating new
> > processes could
> > help get better "realtime" support.
> > * CMake is used to generate the project: cmake -G"MinGW Makefiles" .
>
> I'd be interested in trying this, and comparing to the port needing
> msys, but was hoping you could provide a little more information.
>
> You didn't use msys, but did you update any of the tools that the
> default mingw32 installer provided? (eg bash, the coreutils) Did you
> install any other additional tools into mingw? (eg autoconf)

I used the mingw32 5.1.4 installer and installed these packages:
runtime=mingw-runtime-3.14.tar.gz
w32api=w32api-3.11.tar.gz
binutils=binutils-2.16.91-20060119-1.tar.gz
core=gcc-core-3.4.2-20040916-1.tar.gz
gpp=gcc-g++-3.4.2-20040916-1.tar.gz
g77=gcc-g77-3.4.2-20040916-1.tar.gz
make=mingw32-make-3.81-2.tar.gz

I use g77 for lapack in another project. Should not be necessary for this though. I don't use autoconf and I don't use the mingw bash (is that even included in the installer?).

>
> Did you compile boost within mingw using mingw's gcc? Which version of
> boost? Without MSYS, I presume this was done in a DOS command prompt?
>

I use boost 1.34.1 and for the Orocos compilation I use headers only. Though for faster execution and other projects that actually rely on the libraries I've installed precompiled libraries. I found the boost build system (BJam) a little triggy to use so I went for the easy solution... Though Boost should compile just fine with MinGW.

I use a DOS prompt, yes. Though I develop using Eclipse/CDT so most of the time I avoid the DOS prompt.

> Did you compile CMake from source or download a binary Windows
> installer?
>

I used the installer, no need to make it more complicated than necessary ;)

> TIA
> Stephen

/Jimmy

On Monday 02 February 2009 15:01:05 S Roderick wrote:
> On Feb 2, 2009, at 06:08 , Jimmy Jorgensen wrote:
> ...
> > * CMake is used to generate the project: cmake -G"MinGW Makefiles" .
>
> Looks like a great start! Couple of things after looking this over. It
> appears to mix together at least a couple of patches
> 1) MinGW native thread support
> 2) boost tests intead of cppunit tests
> 3) addition of user-specific CMAKE environment variables
>
> I don't think we should mix together all 3 of these in one patch.
> Makes it harder to test, harder to integrate, and harder to pull apart
> should something be found incorrect later.

I agree, the patches should at least be split when comitting on trunk. There's
also a point 4): addition of new type lookup system. Which was pulled from my
cygwin patch. All in all, the patch only slightly modifies existing code. The
biggest modification is 4), which _i_ should have posted as a separate patch
:-)

>
> Re 2), it's a project level decision whether to change to a new test
> framework. And then this would need to be ported to all aspects of
> Orocos.

libcppunit is very basic and looks like it's having little evolution. With
boost/tests, you're damn sure about future availability and portability. So I
don't oppose a transition, but I'll read the boost/tests docs first though.

>
> Re 3), is this to get around not being able to set CMAKE_INCLUDE_PATH
> and brethren, when building out of an IDE?

We use a similar system as the patch when building Debian packages, but we
specify the include file at the cmake command line. The new orocos-
rtt.default.cmake file is pretty well documented, but should be noted in the
installation manual as well...

>
> It also appears to change "uint" to "unsigned int" throughout. I'm not
> sure why RTT originally used the uint form, but we should check into
> that before such a whole sale change.

These are really fixes on only 4 lines.

>
> This appears to be a replacement patch vs the pthreads one I proposed,
> right?
>
> Which tests failed? As Peter asked me previously, can you post a test
> log.
>
> Perhaps we should create a branch in RTT to put these patches on, same
> as we did for the Mac OS X port?

I'll do so personally in my git repository. You can check out git on windows
using eclipse and the git eclipse plugin (egit) which has no dependencies on
git itself and is very actively developed.

Peter

Hey,

> How is a normal Windoze install going to support "realtime" in any
> sense of the word? Isn't it the same problem as the Mac port - the OS
> fundamentally can't support realtime (unless you get into WinCE I
> guess).

Well yes you are absolutely correct. That was actually my intension with the quotation marks but okay i won't use realtime again. Though Windows actually call the highest priority on a process for Realtime (at least in the task manager).

> I don't think we should mix together all 3 of these in one patch.
> Makes it harder to test, harder to integrate, and harder to pull apart
> should something be found incorrect later.

I guess you are right. It was solely for my own convenience that boost tests and CMAKE env variables was added.
Though I haven't been able to compile and use CPPUnit with mingw, which is why I ported the tests to Boost tests.

> Re 2), it's a project level decision whether to change to a new test
> framework. And then this would need to be ported to all aspects of
> Orocos.

Sure, again I did it for my own convenience. Though using boost test would remove a library dependency from Orocos and CPPUnit looks alot like Boost tests( at least in the way its used in RTT)

> Re 3), is this to get around not being able to set CMAKE_INCLUDE_PATH
> and brethren, when building out of an IDE?

Ehh, well actually in our project we have all configurable variables in an include file like this. Its probably the wrong way to utilize CMake but it seems like an easy and flexible way to add groups of variables with documentation. As i understand it, in orocos you would have to go to config dir where different cmake files document different options? or use CMakeSetup...

And well in windows things are not allways laid out perfectly, say include directories, libraries and such. These need to be specified manually.

> It also appears to change "uint" to "unsigned int" throughout. I'm not
> sure why RTT originally used the uint form, but we should check into
> that before such a whole sale change.

It appear only a couple of places...

> This appears to be a replacement patch vs the pthreads one I proposed,
> right?
>
> Which tests failed? As Peter asked me previously, can you post a test
> log.
>
> Perhaps we should create a branch in RTT to put these patches on, same
> as we did for the Mac OS X port?

Well pthreads are probably safer ;) though i think using native windows gives better opportunities regarding priorities on threads and processes.

I will look into posting the logs.

Cheers,
Jimmy

-----Original Message-----
From: S Roderick [mailto:kiwi [dot] net [..] ...]
Sent: 2. februar 2009 15:01
To: Jimmy Alison Jørgensen
Cc: orocos-dev [..] ...
Subject: Re: [Orocos-Dev] [Bug 605] Initial RTT port for Windows/cygwin

On Feb 2, 2009, at 06:08 , Jimmy Jorgensen wrote:

> For more infomation about this bug, visit <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=605
> >
> --- Comment #4 from Jimmy Jorgensen <jimali [..] ...> 2009-02-02
> 12:08:57 ---
> Created an attachment (id=380)
> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=380)
> MinGW32 support for orocos-rtt
>
> * it is based solely on mingw32, no msys or cygwin.
> * it use native windows threads. No need for pthreads.
> * only ports RTT, and currently without support for Corba
> * it uses the fixes that Peter made regarding 'weak' symbol handling.
> * 4 out of 8 tests work. (ported CPPUnit to BOOST tests since
> CPPUnit requires
> the obnoxious automake )
> * Priorities are supported on thread level, though creating new
> processes could
> help get better "realtime" support.

How is a normal Windoze install going to support "realtime" in any
sense of the word? Isn't it the same problem as the Mac port - the OS
fundamentally can't support realtime (unless you get into WinCE I
guess).

> * CMake is used to generate the project: cmake -G"MinGW Makefiles" .

Looks like a great start! Couple of things after looking this over. It
appears to mix together at least a couple of patches
1) MinGW native thread support
2) boost tests intead of cppunit tests
3) addition of user-specific CMAKE environment variables

I don't think we should mix together all 3 of these in one patch.
Makes it harder to test, harder to integrate, and harder to pull apart
should something be found incorrect later.

Re 2), it's a project level decision whether to change to a new test
framework. And then this would need to be ported to all aspects of
Orocos.

Re 3), is this to get around not being able to set CMAKE_INCLUDE_PATH
and brethren, when building out of an IDE?

It also appears to change "uint" to "unsigned int" throughout. I'm not
sure why RTT originally used the uint form, but we should check into
that before such a whole sale change.

This appears to be a replacement patch vs the pthreads one I proposed,
right?

Which tests failed? As Peter asked me previously, can you post a test
log.

Perhaps we should create a branch in RTT to put these patches on, same
as we did for the Mac OS X port?

Cheers
Stephen

Hey Philippe,

Regarding CORBA i guess it should not be a problem to incorporate it into the built, especially since you had no problem compiling it under mingw. I haven't done it because we currently don't use this feature. I think perhaps i will try this next (when the last bugs are fixed:).

Hmm, i tried compiling RTT under Visual Studio. I had a bunch of errors related to Spirit. But we where able to port RTT 1.2 (or was it 1.0) to Visual Studio so i think that it should be duable for 1.6 with this patch and some additional fixes. I use CMake to generate the Visual Studio projects. Though compile flags and definitions are currently set to use a gcc compiler. This should be fixed.

Cheers,
Jimmy

Hi Peter,

I'm not sure that my patch would be ready for review yet. At least some main functionalities are still needed:
*The use of native windows threads should be modified to include better support for processes priorities.
*I never did manage to get cppunit to compile under mingw and as such I have not been able to test Orocos in full.

I have not experienced any trouble with the part of orocos that i use. Though i only use a relative small part of RTT. I guess i need the complete test suite before being able to answer your question on your technical note.

I will try and port some of the tests to boost tests in this week. With some luck i can post the results with my patch in the midle of next week.

/Jimmy