Re: [MiNT] compiling a kernel

[Martin-Éric Racine <q-funk@pp.fishpool.fi>]

On 2000-5-6, Guido Flohr <gufl0000@stud.uni-sb.de> wrote:

> The necessary changes are quite trivial and the overlay seems
> to need a new maintainer anyhow.

Trivial:  something that is supposedly so easy that nobody ever
          gets around it, because the job lacks prestige.
(source:  Slashdot)

> IMHO it was a mistake to include GEM headers at all in the
> MiNTLib.

What differenciates MiNT from Linux is simple:  GEM.

> To avoid this, Christian has renamed the headers.  But he has changed the
> binary interface to the library as well. 

> > Besides, keeping vdibind separate from the AES made sense, as you
> > will find out if/when you actually try building a new X11 port.
> > In this case, you would be calling the VDI, but no single AES 
> > function, so why include the whole GEM binding, then?
> 
> In fact I agree.  But I am the wrong address for your
> proposal.  Christian is the maintainer of the gemlib and it
> is his decision.

Where is Christian these days?  He seems just about as present as
Howard, nowadays. Seems both GEMLIB and TosWinII are in need of a
new maintainer.

> I would actually prefer to split up the GEM (AES and VDI)
> headers even more.  That would increase readability and would
> also avoid name conflicts.

Agreed, although, IMHO, excessive modularization becomes
fragmentation.  Separating GEM into:

* VDI
* AES up to 3.20
* AES since 3.30 (including MultiTOS extensions)

...should be sufficient.  These could be called:  

* vdi.h
* gem.h
* gemx.h

...which is not too distant from the current naming scheme. The
headers could recursively include each other, in this order:

* gemx:  gem.
* gem:   vdi.
* vdi:   (stdio, etc.)

This way, one only needs to include the highest GEM level needed
to code the application.  Every other sub-level is included: 

When coding an application that uses 3D objects and colour icons,
use GEMX; when coding a basic GEM application, GEM; when making a
new window manager or GUI, use VDI.

(of course, this logic could be expanded so that, coding a CLI
application only requires basic console support, etc.)

-- 
Martin-Éric Racine  http://funkyware.atari.org/  Atari TT030 FAQ
Lappeenranta, Finland.  Surfing on a Intel/Microsoft-free GEM OS