Re: documentation typo

Hi Damian,

Damian Menscher wrote:
> http://www.gnu.org/software/m4/manual/m4.html
> 
> s/woould/would/

Thanks.  Now fixed in CVS.  The web manual won't be updated until
the next release though.

Cheers,
	Gary.
--

-- 
Gary V. Vaughan      ())_.  gary <at> {lilith.warpmail.net,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

_______________________________________________
Bug-m4 mailing list
Bug-m4 <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-m4

Re: recursive push_string with non-gnu cc

Hallo Ilya,

Ilya N. Golubev wrote:
> 
> 	* input.c (match_input): Do not pass expression with
> 	side effect to `obstack_grow'.  Fix <INTERNAL ERROR: Recursive
> 	push_string!>.

Thanks, applied to branch_1-4.

Cheers,
	Gary.
--

-- 
Gary V. Vaughan      ())_.  gary <at> {lilith.warpmail.net,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

_______________________________________________
Bug-m4 mailing list
Bug-m4 <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-m4

m4 should check for gnugetopt, gnuregex already present on the system

FreeBSD, as well as -- I'm sure -- all Linux distributions already have
both the GNU getopt and the GNU regex functionality available -- either
as part of (g)libc or as additional libraries.

Using those will help cut the m4-executable's size (30% on my
FreeBSD/amd64), as well as avoid the bugs already fixed by the later
revisions of these libraries.

m4's configure should check for these and avoid compiling m4's own
regex.o and getopt*.o

Attached is the patch, I'm trying to include into FreeBSD port of m4 --
it should help illustrate, what I'm talking about.

Thanks! Yours,

	-mi

_______________________________________________
Bug-m4 mailing list
Bug-m4 <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-m4

Re: m4 should check for gnugetopt, gnuregex already present on the system

According to Mikhail Teterin on 12/14/2005 10:15 PM:
> FreeBSD, as well as -- I'm sure -- all Linux distributions already have
> both the GNU getopt and the GNU regex functionality available -- either
> as part of (g)libc or as additional libraries.
> 
> Using those will help cut the m4-executable's size (30% on my
> FreeBSD/amd64), as well as avoid the bugs already fixed by the later
> revisions of these libraries.
> 
> m4's configure should check for these and avoid compiling m4's own
> regex.o and getopt*.o

If you are patient enough, m4 CVS head (which will become m4 2.0) already
does this.  m4 2.0 has a dependency on the release of libtool 2.0, but it
uses the gnulib version of regex which can detect whether or not it is on
a system with a new enough glibc to avoid compiling the replacement
version.  However, be aware that there are still known bugs in the glibc
regex, which are not present in the gnulib version, such as POSIX
compliance issues on 64-bit platforms, so even then, the gnulib version
might be selected unless you explicitly use a ./configure option to use
the (potentially buggy) platform version.

> 
> Attached is the patch, I'm trying to include into FreeBSD port of m4 --
> it should help illustrate, what I'm talking about.

Patching the 1.4 branch of CVS is not worth it at this point, but thanks
for your efforts anyways.  However, you are free to patch the FreeBSD port
if you wish; after all, m4 is free software.

Re: m4 should check for gnugetopt, gnuregex already present on the system

> However, be aware that there are still known bugs in the glibc
> regex, which are not present in the gnulib version, such as POSIX
> compliance issues on 64-bit platforms, so even then, the gnulib version

The reason I noticed the current redundancy on the FreeBSD port, is the number 
of compiler-warning generated during the compilation of m4's own regex.c on 
FreeBSD/amd64

The functionality is available on FreeBSD as part of -lgnuregex, which -- at 
the moment -- is built from the following sources: fedora-glibc-2_3_4-21. Are 
you aware of bugs in this version? Regardless of m4, we should fix them here 
-- can you offer links to patches and/or test-cases?

> > Attached is the patch, I'm trying to include into FreeBSD port of m4 --
> > it should help illustrate, what I'm talking about.
>
> Patching the 1.4 branch of CVS is not worth it at this point, but thanks
> for your efforts anyways.  However, you are free to patch the FreeBSD port
> if you wish; after all, m4 is free software.

The port's new maintainer pretends to hold an opinion, that this issue must be 
addressed by the software's vendor (you), rather than by the port 
(him)  We'll see...

Thanks for your time! Yours,

	-mi

Re: m4 should check for gnugetopt, gnuregex already present on the system

According to Mikhail Teterin on 12/16/2005 10:03 AM:
> The functionality is available on FreeBSD as part of -lgnuregex, which -- at 
> the moment -- is built from the following sources: fedora-glibc-2_3_4-21. Are 
> you aware of bugs in this version? Regardless of m4, we should fix them here 
> -- can you offer links to patches and/or test-cases?

First, understand that the gnulib regexp used glibc as its upstream
source.  This URL to gnulib CVS:

http://cvs.savannah.gnu.org/viewcvs/gnulib/gnulib/config/srclist.txt?rev=1.109&view=markup

contains a cross-reference of all the glibc bugzilla entries (search for
$LIBCSRC/posix/reg*, and the open bugs are listed as links above the
affected files) that were created to track differences between glibc and
gnulib.  While some of the bugzilla entries have since been closed, there
are still some known differences, and by reading the bugzilla entries, you
will find instances where gnulib has a patch for POSIX compliance that
glibc has not picked up.  Since m4 2.0 will use the gnulib regexp module
by default, you will be missing out on all these patches to deficiencies
in glibc if you insist on using the glibc regexp.

>>
>>Patching the 1.4 branch of CVS is not worth it at this point, but thanks
>>for your efforts anyways.  However, you are free to patch the FreeBSD port
>>if you wish; after all, m4 is free software.
> 
> 
> The port's new maintainer pretends to hold an opinion, that this issue must be 
> addressed by the software's vendor (you), rather than by the port 

Re: m4 should check for gnugetopt, gnuregex already present on the

Please keep replies on list, so that others may see them in the archives,
and so that you are more likely to get a decent response.  I am not the
official m4 maintainer, only an interested party since I maintain the
cygwin distribution of m4.  The maintainer, Gary Vaughn, is currently
occupied with putting finishing touches on libtool 2.0 at the moment.

According to Mikhail Teterin on 12/17/2005 12:11 PM:
>>Since m4 2.0 will use the gnulib regexp module by default, you will
>>be missing out on all these patches to deficiencies in glibc if you
>>insist on using the glibc regexp.
> 
> 
> I don't, actually, insist on one over the other -- I just don't want to
> see two (slightly different) versions of the same thing.

Then YOU try convincing the glibc maintainers to fold in all the gnulib
regexp patches (it's a tough job, as Paul Eggert already found out).

>  
> 
>>Then you can offer to help by speeding up the release of libtool 2.0,
>>so that the release of m4 2.0 can follow.
> 
> 
> Sorry, my plate is overfilling already. That said, I don't understand,
> how libtool, which is merely a tool for software building, can delay a
> release of the software itself.
> 
> Can't you put it into a README to use the compiler and linker directly?