Re: [Opentnl-general] Porting Question
Brought to you by:
mark_frohnmayer,
s_alanet
From: Boris K. <Fli...@in...> - 2004-10-26 18:13:06
|
Mark Frohnmayer wrote: > Hi Boris, Hi Mark ! > The one gotcha for TNL as far as multiplatform capability is that the > RPC mechanism uses specialized assembly language functions to read stack > arguments and then dispatch the function call on the remote host. okay, I see - does that mean, that we might have better chances if we simply decided not to use TNL's RPC functionality ? > I'm currently working on a version of that code that uses templates instead, > that should be totally ross-platform. sounds good ! :-) > What platforms are you looking at porting to? actually, we didn't yet really look into specific platforms, rather we did "by accident" notice that TNL doesn't seem to compile on each platform that easily. That's also when we checked the exact description on the webpage and noticed the remark that it would generally only compile on three different platforms, that's where we stopped to look into the details. The platforms where we encountered said problems were mostly typical unix platforms (SGI/Irix) if I remember correctly. Also, the TNL webpage reads that there's currently only support for x86 linux ? A maximally platform-independent implementation would be preferable because we could use the TNL for all components of our project, while we would otherwise be forced to use the TNL stuff only for the client side because most usual server platforms aren't yet supported. I am sure that other users of your library would probably also benefit from such an almost "platform-independent" implementation. > You can look at tnlMethodDispatch.cpp/.h for the architecture specific > assembly code. Okay, thanks for that hint - I am going to look into it, but actually we wouldn't want to mess around with assembly code. How much work do you think is involved in porting the current assembly code-based approach over to a pure C++/template oriented one ? Depending on the amount of time that might take, we could meanwhile try to determine where exactly the TNL sources need to be modified in order to compile with recent versions of GCC - if that'd help. Additionally, I would have personally found it helpful if the library had been packaged like a standard GNU tarball, including a conventional configure/makefile build chain, possibly with a central default location where to place the header files - what do you think ? Thanks -------- Boris |