Re: [Opentnl-general] Porting Question
Brought to you by:
mark_frohnmayer,
s_alanet
From: Boris K. <Fli...@in...> - 2004-10-27 06:26:08
|
Mark Frohnmayer wrote: > Boris Koenig wrote: > >> Mark Frohnmayer wrote: >> >> okay, I see - does that mean, that we might have better chances if we >> simply decided not to use TNL's RPC functionality ? >> > Much of TNL's higher level functionality (GhostConnetion) depends on the > RPC stuff working, so although you could strip it out, you would lose > much useful functionality. This may or may not be an issue depending on > your application. I was merely trying to get some feedback whether not to use RPC functionality would solve some of the porting issues. As John said already: being able to use RPC would definitely be "nice". >> Also, the TNL webpage reads that there's currently only support >> for x86 linux ? > > > For linux, yes. It should also be a trivial port to PPC linux, since > there's a PPC version of the assembly code for OS X. I seel, well I don't think it's necessary to do that - because if the general plans are to slowly migrate over to a template based approach for the platform specific code, it should not be that important for us - regardless of how long the actual migration is going to take. >> 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. > > > Of course... though x86 linux is a fairly common server platform. yes, certainly right - but there's so much POSIX stuff that people use ... x86 is probably not always the first choice. >> 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. > > > It should compile fine with GCC 2.9.5 and 3.x I haven't had problems with that personally, but I think John can comment on that ? >> 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 ? > > > We currently don't have a Unix master on the project to manage such a > thing. Are you volunteering? lol, well I wouldn't mind to look into it in more detail, I just noticed that the current Makefiles mention that you ultimatley intend to switch to autconf/automake, so a first stab at it would probably not be a bad idea, one could still keep the old makefiles around as a fallback solution. ---------- Boris |