[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Updating FreeBSD port

From: Mikhail Teterin
Subject: Re: Updating FreeBSD port
Date: Wed, 20 Sep 2006 17:33:25 -0400
User-agent: KMail/1.9.1

середа 20 вересень 2006 17:12, Paul Eggert написав:
> Mikhail Teterin <address@hidden> writes:
> > However, there is not a single place anywhere in m4's code (outside of
> > getopt*.c), where optind is set to zero.
> Other gnulib-using programs do rely on that functionality, though, so
> we test for it in gnulib.
> It's not worth the configuration hassle to make the test depend on
> whether the GNU program actually needs the functionality.  There are
> lots of fiddly bits of functionality in gnulib and we don't have time
> to maintain configure-time options for them all.  It's simpler just to
> have ./configure ask "is libc compatible with our replacement?" and to
> use the replacement if the answer is "no".

My concern was for m4 only :-) It was Eric, who added gnulib to the list of 
CC. If *gm4* is not going to trip over any getopt_long differences, then it 
is safe for it to not use its own implementation.

> > whatever problems/quirks there exist with GNU
> > regex, they (along with the fixes) should be the same for all
> > applications...
> Absolutely, and that's the long-term solution.  But the situation
> right now is as I described.

:-( Are there regex-patches currently waiting to be merged into GNU's libc? 
FreeBSD may be able to incorporate them faster...

> >     Does running `gmake check' after building gm4 and getting all tests to
> >     succeed, constitute a comprehensive test? Are all aspects of m4 being
> >     covered?
> No, the tests are incomplete.


> That incompatibility is fixed in gnulib regex.  It's one of the bug
> fixes that hasn't migrated into glibc, but we plan for it to do so
> eventually.  This should address your objection about naming
> conventions, and should make it possible for BSD to support the GNU
> features as extensions.
> The basic idea is that if BSD libc supports the gnulib regex interface
> and pass the tests in m4/regex.m4, GNU programs will run lean and mean
> on BSD hosts.

We are, actually, fairly comfortable using the "good old" regex and 
offering -lgnuregex for applications needing GNU implementation. If anything, 
I'd prefer regex maintainers to concentrate on bug-fixing, than compatibility 
with the traditional Unix regex interface(s).

If the compatibility were there from the beginning -- great, but now there are 
already solutions in place and it is not as important as correctness, that 
you say is not there.

Lastly, the whole libc, glibc, and gnulib collection is quite confusing and 
bewildering :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]