> i want to know how portable ggi is
I hope it is very portable ... :-). That is what we intended.
> (is all ansi c?
Almost. There are some places, where we assume posix or some system specific
stuff, but that should all be catched by autoconf and the relevant
subsystems should not be built when the functionality isn't available.
> how much percent is portable?
The core system itself should be >80% portable. As said, some drivers and
stuff will disable themselves, which is of course right, as the target
system doesn't have the corresponding drivers/concepts anyway.
Regarding KGI I can assure you, that it is 100% portable even to totally
non-Posix environments.
LibG* will need to get some alternate code in some places (like for
dynamically loading the sublibs).
> what is the first module to be port?
What do you need ? Is there already a hardware layer ? if not, you will
have to start out with KGI by writing another HA/OS glue layer like
fbcon-kgi.c . I can help you with that one, if you have trouble.
> what enviroment are needed
Basically an ANSI-C compiler. More Posix stuff would help, but isn't
required.
> i really like ggi and ggi/picasso project but i think it is too linux
> (posix) glued!
I really hope it isn't. Though most OSes are moving toward providing at
least a posix emulation layer ...
> i am looking very close the aros progress, and by now there is some
> discussion about a 3D api (what apear mesa to be the win), and i
> would like to show ggi as an alternative.
GGI does not replace Mesa in any way. There is ggiMesa in the mesa build
tree, which makes Mesa run over GGI.
> i don't thin ggi could fit only on the 3D api, but on much more, aros
The main point about GGI is being _generic_.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
