[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
covered?
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.)
Yours,
-mi
- Updating FreeBSD port, Mikhail Teterin, 2006/09/20
- Re: Updating FreeBSD port, Eric Blake, 2006/09/20
- Re: [bug-gnulib] Updating FreeBSD port, Bruno Haible, 2006/09/21
- Re: Updating FreeBSD port, Eric Blake, 2006/09/21
- Re: Updating FreeBSD port, Mikhail Teterin, 2006/09/21
- Re: Updating FreeBSD port, Eric Blake, 2006/09/21
- Re: Updating FreeBSD port, Mikhail Teterin, 2006/09/21
- Re: Updating FreeBSD port, Eric Blake, 2006/09/21