Re: [MiNT] compiling a kernel

["Guido Flohr" <gufl0000@stud.uni-sb.de>]

Hi,

On Sat, May 06, 2000 at 10:24:33PM +0300, Martin-Éric Racine wrote:
> > Howard should change the sources like this:
> 
> Howard is nowhere near available to handle much of anything,
> anymore.  I recently contacted him about some problems with
> my bank's web site and cookies and, unfortunately, his days
> on MiNT are over.  He still has his TT, but has started his
> own business and has no time left for so many hobbies.

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

> > As for the "missing" aesbind.h, vdibind.h, gemfast.h:  I have
> > removed them because they are part of the GEM library and not
> > of the libc, and furthermore they didn't match anymore with
> > the GEM library itself.  It would probably make sense to add
> > the headers for compatibility to the GEM library (only
> > consisting of an "#include <gem.h>).  But I am not the
> > maintainer of libgem.a.
> 
> It would make sense never to remove anything you cannot replace
> with something else.  Scraping something and then saying "well,
> let him fix it, it's not my department" is not constructive.

I think you are wrong here.  A library should only install header files
that contain declarations for features it offers itself.  This should
actually be common agreement.

IMHO it was a mistake to include GEM headers at all in the
MiNTLib.  If <aesbind.h>, <vdibind.h>, and <gemfast.h> were still part of
the gemlib then the MiNTLib and the gemlib would subsequently overwrite
the headers of the other package at each installation.  A bad idea.

To avoid this, Christian has renamed the headers.  But he has changed the
binary interface to the library as well.  If I would still install the
MiNTLib headers, then the function prototypes would not match the function
definitions.  But if you call an external function with the wrong
arguments (wrong number or wrong type) the program is very likely to
malfunction or crash.  There is no way to find such errors at compile or
link time.  If the headers conflict with the binaries, then I can just as
well remove them so that such errors will be noticed at compile time.

In other words: It is possible that it wouldn't help at all to still
provide the headers.  There /are/ compatibility problems and it is better
to make people aware of them at compile time than at run-time.

> Besides, keeping vdibind separate from the AES made sense, as you
> will find out if/when you actually try building a new X11 port.
>   
> Sure, you could create yor own primitives and display routines,
> but using the VDI makes much more sense and remains much more
> hardware-independant.  In this case, you would be calling the
> VDI, but no single AES function, so why include the whole GEM
> binding, then?
> 
> Just a thought. :)

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.

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.

Ciao

Guido
-- 
http://www.stud.uni-saarland.de/
Send your spam to president@whitehouse.gov and your replies to
mailto:guido at freemint dot de