[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 14:06:43 -0400
User-agent: KMail/1.9.1

середа 20 вересень 2006 13:24, Paul Eggert написав:
> Mikhail Teterin <address@hidden> writes:
> > I see -- would you have a test-case, that detects this difference?
> No, but you can read the thread containing this message:
> http://lists.gnu.org/archive/html/bug-gnulib/2004-10/msg00171.html

> to see some of the issues here, and why gnulib getopt.m4 rejects BSD's
> emulation of GNU getopt.

That message states:

        Not if we merely want to test for GNU compatibility.
        BSD getopt_long_only has another incompatibility that we can test for
        at compile-time: it uses the "optreset" global variable to reset
        scanning, whereas GNU getopt_long_only expects you to set optind to
        zero.  This is the basis for the patch I just installed.

However, there is not a single place anywhere in m4's code (outside of 
getopt*.c), where optind is set to zero. The only spot, where it is 
manipulated at all, it is being incremented. Are there other issues?

Is there a real-life example, where BSD's getopt fails for m4?

> >     cvs -z 9 -d :pserver:address@hidden:/cvs/glibc \
> >             co -r fedora-glibc-2_3_4-21 libc/posix libc/include
> >
> > As before, are there tests, that detect incompatibilities?
> There we have quite a few more tests; see
> <http://cvs.savannah.gnu.org/viewcvs/*checkout*/gnulib/m4/regex.m4?root=gnu
> lib>. Even glibc doesn't satisfy the current tests, so there's no shame in
> your failing them too.  I'm working on getting glibc fixed, but these
> things take time.  (To some extent its an arms-race problem as we can add
> tests faster than the libc maintainers can fix the regex
> bugs.... :-)

My objection is to the code duplication. I doubt, gm4 is compiled with its own 
regex on Linux -- I want the BSD's builds to be just as lean. As for bugs, 
whatever problems/quirks there exist with GNU regex, they (along with the 
fixes) should be the same for all applications...

I may not be expressing my question about the tests bundled with gm4 right. 
Let me try again:

        Does running `gmake check' after building gm4 and getting all tests to
        succeed, constitute a comprehensive test? Are all aspects of m4 being

I've been using gm4 with BSD's getopt and -lgnuregex for about a year, and all 
my rebuilds of KDE, gnome, and other autoconf-using packages (all heavy users 
of gm4) were working just fine.

> If it works, I suppose we can try to automate adding the linker magic
> and put that into regex.m4.  But I can't resist asking: why can't the
> BSD folks just make a gnulib-compatible regex be the default?  That
> would make life easier for lots of people.

Because BSD's (Unix) regex was there first :-) BSD 4.4 Lite, incorporated into 
FreeBSD in 1994, had it for quite some time before that -- they were/are used 
by sed and awk -- both parts of the very first Unixes... It is the GNU 
people, who chose a name for their then-new library to clash with an earlier 
one, with which they are NOT compatible. Consequently, it should be the GNU 
people, who should rename their library to avoid the name-clash :-)

(This is not a problem for things like gawk, gmake, or gm4 itself, because 
these tools remain mostly backwards compatible with the non-GNU versions.)



reply via email to

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