Out of curiosity, what hardware do you need to get working?

On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote:

> 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 :
>> 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