Re: Re: [UnixOS2] libc

On Tue, Jul 08, 2003 at 09:40:15AM +0200, Andreas Buening wrote:
> > > Of course, static libraries and headers have to be consistent.
> > 
> > This is not what I meant.  For full compatibility, when a ABI/API-fork
> > (if you know what I mean ;-) is performed, the new functions should
> 
> Not really. ;-)

I mean when functions with "identical functionality" (so the change
can be made transparent via header files), but incompatible ABI or API
are introduced.

> > have different link-time name, and the header files should #define old
> > names into the new ones.  Actually, the same should be done for the
> > old names; i.e., fstat() should be replaced by fstat32() and fstat64()
> > - with "purely named" fstat() also sitting somewhere for the sake of
> > ./configure scripts.

> For configure scripts only the linker needs to find them. So fstat
> will be most likely only exist in the import library and will be an
> alias for fstat64.

[Some configure scripts check the header files too - but this should
not be a problem.]

> > > We'll see. Btw, where have gone all the volunteers who wanted to host
> > > the new emx CVS?

> > It may be ignorance, but in many years of my experience I never saw a
> > situation when CVS helps.
> 
> We need a central source archive, anyway.

In my experience, a mailing list archive serves this purpose well
enough.  [Why I object to CVS: it creates a warm cozy filling that
things are settled up.  This filling is counterproductive - e.g.,
since it is wrong. ;-]

> > > 1. Restructuring of the current emx build system (no idea how much
> > >    work would be necessary for this) to make sure the new build
> > >    system works before we change anything.
> > 
> > IMO: DO NOT do this.  Use 2.8.1 + dmake.
> 
> Somebody mentioned that the current emx build system should be improved
> if I remember correctly. I haven't looked closely at this, yet.
> If we want to do this we should do it right at the beginning.

I repeat:

  a) I know of no issue with 2.8.1 + dmake (but of course, this may be
	just ignorance).

  b) I see no reason to do this "in the beginning" (actually, I do not
     see any reason to do this at all, if it requires more than man-hour of
     work).

> Of course, it isn't necessary to have a _compatible_ release but

???  You probably missed another negative?  I see no need for
uncompatible release...

> it is (IMHO) necessary to have a _working_ release directly at the
> beginning so we can revert to this working version if anything goes
> wrong.

Again, I do not follow.  All the releases should be treated this way...

Yours,
Ilya