I'm not sure that "project fork" is a best way. Because hardware problem is a little piece of work and it's lays it separate module. The biggest part of application is a some computations and some algorithms implementation...As far, as application was port in many different Linux platforms, it's almost impossible to find some function with out #ifdef :))
Ok, any way, it looks like "project fork" is simplest way to do port, so any other ways is not very interesting. I think that this way is most correct, because in that case i could redesign many parts of this application in "plan9 style", do some soft services like, files for example :) Thanks to all for your help :) 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>: > You need to do direct hardware manipulation? Then "project fork" is > probably best. > > On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote: > > > Heh, i try to "port" my program, and it's really not possible in my > > point of view :) > > > > Actually, i don't have working Plan9 right now, reason is quite > > simple, on my hardware plan9 does do not work (PC emulators couldn't > > help because my program should work with some special hardware), so i > > try to create PC from "supported hardware" list, but it take some > > time to get all pieces, put they together, install, configure plan9 > > and so on )) > > Ok, i have no Plan9, but i have my application that i want to port, > > so i try to remove all autotools macros from it and try to do some > > preparations, like new abstraction layer for threads creation...and > > i'm completely failed, just because too much autotools stuff in > > sources. And it too complicated to figure out what exactly i should > > remove in every case... > > And my application much smaller that mesa for example. Or X11 (by the > > way, how X11 was ported?), and i do not touсh such problems like > > different library, kernel interfaces and so, and so... > > > > So it looks like "project fork" is only way :( > > > > 2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>: > >> On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > >>> Circular cause and consequence is funny. Let me add to this list: > >>> - jpg > >>> - png > >>> - tiff > >>> - PostScript > >>> - TeX (tpic) > >>> - HTML > >>> - Mahjongg, sokoban, sudoku, tetris (games/4s) > >>> - SPARC, MIPS, x64 > >>> - MP3, PCM, OGG (PAC was made at Bell Labs) > >>> - SoundBlaster 16 > >>> > >>> Let me put it this way: > >>> GNU software is good, except for GNU development tools, > >>> which, > >>> except for the gcc program itself, are mediocre and break > >>> compatibility (try using a Bell Labs makefile with GNU make). > >>> > >> > >> I'd add to it the fact that autotools source files are hard to > >> make, so > >> many people who are to lazy to do it properly just put the famous > >> (in)sanity check and checks for libs they use. The effect? > >> > >> A simple C program that doesn't rely on anything except for > >> example libpng > >> will check for C, C++, FORTRAN 77 compilers, check if those are from > >> GCC and various other things. > >> > >> Imagine my surprise when I had seen a configure script (for EmacsLisp > >> utility) that only checked for Emacs version > >> and few EmacsLisp files it used - a rare thing IMHO, when >80% of > >> configure running time is for checking for not used > >> software. > >> > >> "CPU cycles are cheap, programmer time is expensive" <--- This > >> doesn't > >> mean that total laziness is appropriate. > >> > >> The best thing about autotools is I think the scheme of running > >> configure - AFAIK mplayer doesn't even use configure for it's script, > >> instead > >> they use their own, which looks the same to end user. And saves a lot > >> of time :-) > >> > >> -- > >> Paul Lasek > >> > >
