Re: Re: [UnixOS2] libc

Ilya Zakharevich wrote:
> 
> On Sun, Jul 06, 2003 at 10:24:06PM +0200, Andreas Buening wrote:

[snip]

> > 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. ;-)

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

[snip]


> > > P.S.   But unless EM says otherwise, I think that without a volunteer
> > >        maintainer all this is going to be a pipe dream.
> 
> > 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.


>   It is *crucial* that the patches fly through a mailing list (or,
>   better, an mailing-list/archived-newsgroup combo) - so that as many
>   people as possible can comment on this.

ACK. If we have no maintainer we need at least some quality control. :-)

[snip]

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


> There are *pressing needs* to fix things.  Restructuring is a luxury
> with no (?) known benefits.
> 
> > 2. Appliance of all known bug fixes to emx and the last 100%
> >    compatible emx release (0.9g) as a proof of concept.
> 
> AFAIK, there is no need to have the *last* compatible release.  The
> amount of work to make new releases compatible is muniscule comparing
> to QA work.  And in the absense of QA framework it is crucial to have
> a large pool of applications which have a chance to break due to
> yet-uncovered bug - so we can fix this bug early ;-).

Of course, it isn't necessary to have a _compatible_ release but
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. And in this case it makes sense to make the first working
release also a compatible release. When applying the (few) bug fixes
we'll see where the possible bottlenecks are of our mailinglist/CVS
system and whether it works at all.


Btw, could reply to the UnixOS/2 list directly by 'to' not by 'cc'?
cc'ed posts seem to get lost.


Bye,
Andreas