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 :
>> On Feb 3, 2008 2:55 AM, Pietro Gagliardi 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
>>