Re: 2.2 projects

[Zack Weinberg <zack@rabi.columbia.edu>]

On 28 Jan 1999 13:12:01 -0800, Ulrich Drepper wrote:
>Zack Weinberg <zack@rabi.columbia.edu> writes:

>> - build overhaul
>
>Yes, but given the constraints that we certainly don't want to require
>a 200MB RAM machine as it would be necessary if we go away for
>recursive make calls.

Nonrecursive make is in the far future.  I'm talking about things like
the patch for configuration, make dist, etc. that you told me to wait
on last August, some other changes that that enables, moving all the
built libs up to top level (dependencies get much simpler and we can
put stuff in extra libs from several places), using wrapper headers to
get the -I list down to something sane, etc. etc.

Paul Smith has some plans for make that will hopefully cause it to
consume less memory.

>> - new test framework
>
>Hum, I'm not really convinced.  I have to work all the day with
>dejagnu and I hate it.

I hate it too - so I rewrote the driver in shell.  No extra tools are
needed. 

>I must admit I haven't really looked at Zack's rewrite of the code.
>If it is still possible to use `make check' as before I'd have no
>problems.

This will work as soon as the top level Makefile is changed to call
the testsuite directory instead of doing what it does now.

>> - OpenBSD extended crypt() [need non-US hacker]
>
>Don't know about this.

Their crypt() supports plug-in algorithms with switching based on the
salt.  I don't know exactly how it works.  

>> - default to BSD network headers (?)
>
>What do you mean by this?

PR 143, I think it is.  Linux does <netinet/tcp.h> and a couple others
differently from every other Unix.  If we change it, it will break
source compat, so we need to think it through carefully.

>> - better regexp library
>
>Yep, one of my bluesky projects.  I really would like to do this once
>there is no urgent change.

I looked at Harry Spencer's recent stuff, it looks much faster than
ours, but it would have to be hacked to support the syntax extensions.

>> - tighter namespace cleanliness in POSIX mode, XPG if possible
>
>Hhm, there shouldn't be any violations except for missing function
>definitions.

I get a pile of illegal macro definition warnings under
_POSIX[_C]_SOURCE.  I don't really trust annexc.c though, I've been
meaning to tighten it up but I need a copy of the standard to do it
with.

zw