[sr #110266] Revert regression in Yacc support, and add Bison support

Update of sr#110266 (group autoconf): Priority: 1 - Blocked => 3 - Release N+1 ___ Reply to this item at: ___

Re: bug#50469: [bison-3.8] bug or side effect to flex & automake

On Wed, Sep 8, 2021, at 1:31 AM, Akim Demaille wrote: > One big problem with the Autotools as of today is that they promote > the use of macros/build rules for Yacc, not for Bison. The contract of AC_PROG_YACC is to find something that will generate parsers from POSIX-compliant input; all

[sr #110266] Revert regression in Yacc support, and add Bison support

Update of sr #110266 (project autoconf): Priority: 5 - Normal => 1 - Later ___ Follow-up Comment #2: Yeah, I think AC_PROG_BISON would be 2.71 material at this point. Considering the course of

[sr #110266] Revert regression in Yacc support, and add Bison support

Update of sr #110266 (project autoconf): Status:None => In Progress ___ Follow-up Comment #1: Thanks for reporting this. I started the ball rolling on it by reverting the mistaken patch in

[sr #110266] Revert regression in Yacc support, and add Bison support

URL: <https://savannah.gnu.org/support/?110266> Summary: Revert regression in Yacc support, and add Bison support Project: Autoconf Submitted by: haible Submitted on: Tue 14 Jul 2020 09:47:21 PM CEST Category

Re: Yacc support vs. Bison support

Hi all, > Le 8 déc. 2018 à 00:48, Bruno Haible a écrit : > > How does that sound? As far as I can see, this would solve the problems > (A), (B), (C) in the Bison support, while at the same time not regressing > behind 2.69 regarding the Yacc support. It sounds excellent to me.

Yacc support vs. Bison support

Hi, Up to version 2.69, Autoconf has - good support for Yacc-syntax sources, - mediocre support for Bison-syntax sources. Let me distinguish - Yacc programs, that follow the POSIX specification http://pubs.opengroup.org/onlinepubs/9699919799/utilities/yacc.html , - Bison programs

Re: flex and bison in autoconf

Hi, AC_PROG_YACC #if test x$YACC != xyes; then # AC_MSG_ERROR([Please install bison before installing.]) #fi AC_PROG_LEX if test x$LEX != xflex; then AC_MSG_ERROR([Please install flex before installing.]) fi ... The problem is, while running ./configure built from this file, do

flex and bison in autoconf

install bison before installing.]) #fi AC_PROG_LEX if test x$LEX != xflex; then AC_MSG_ERROR([Please install flex before installing.]) fi AC_CONFIG_MACRO_DIR([m4]) GNOME_DOC_INIT # Compiling sources with per-target flags requires AM_PROG_CC_C_O AM_PROG_CC_C_O AC_PROG_INSTALL #AC_PROG_LIBTOOL

Re: AC_PROG_YACC: use bison -o y.tab.c

Ping! Le 4 mars 2013 à 18:48, Akim Demaille a...@lrde.epita.fr a écrit : Hi Autofolks, The fact that Autoconf sets YACC to bison --yacc is troublesome, as it emasculates the Bison down to a Yacc-calf (I wouldn't like to be the vet performing the bollocksectomy of a Bison). The appended

Re: AC_PROG_YACC: use bison -o y.tab.c

Thanks, I installed that into Autoconf with a slightly terser NEWS entry: - AC_PROG_YACC now uses 'bison -o y.tab.c' instead of 'bison -y', so that by default it no longer warns about Bison extensions. Add -Wyacc to YFLAGS to enable these warnings.

Re: AC_PROG_YACC: use bison -o y.tab.c

Le 19 mars 2013 à 19:20, Paul Eggert egg...@cs.ucla.edu a écrit : Thanks, I installed that into Autoconf with a slightly terser NEWS entry: - AC_PROG_YACC now uses 'bison -o y.tab.c' instead of 'bison -y', so that by default it no longer warns about Bison extensions. Add -Wyacc

AC_PROG_YACC: use bison -o y.tab.c (was: [PATCH 0/6] api.value.type support)

Le 25 févr. 2013 à 14:26, Akim Demaille a...@lrde.epita.fr a écrit : Actually I just found what could arguable called a bug in Bison: $ ls f.y f.y $ bison -o y.tab.c -d -v f.y $ ls y.* y.output y.tab.c y.tab.h where I would have expected y.tab.output. Fortunately

Re: Bison

Hi, On 12/01/11 06:24, John Calcote wrote: On 01/11/2011 04:31 AM, Russell Shaw wrote: Hi, On debian, there is /usr/bin/bison, and /usr/bin/bison.yacc just does: exec '/usr/bin/bison' -y $@ How can i get autoconf to use bison? The problem with yacc is that you can't rename the output

Bison

Hi, On debian, there is /usr/bin/bison, and /usr/bin/bison.yacc just does: exec '/usr/bin/bison' -y $@ How can i get autoconf to use bison? The problem with yacc is that you can't rename the output files and always get: y.tab.h y.tab.c Is there a way i can get yacc to give better output

Re: Bison

Russell Shaw wrote: How can i get autoconf to use bison? The problem with yacc is that you can't rename the output files and always get: y.tab.h y.tab.c Is there a way i can get yacc to give better output file names like myproj.tab.h myproj.tab.c ? Is this really an autoconf question? Seems

Re: Bison

On 01/11/2011 04:31 AM, Russell Shaw wrote: Hi, On debian, there is /usr/bin/bison, and /usr/bin/bison.yacc just does: exec '/usr/bin/bison' -y $@ How can i get autoconf to use bison? The problem with yacc is that you can't rename the output files and always get: y.tab.h y.tab.c

Re: Bison

On 12/01/11 06:24, John Calcote wrote: On 01/11/2011 04:31 AM, Russell Shaw wrote: Hi, On debian, there is /usr/bin/bison, and /usr/bin/bison.yacc just does: exec '/usr/bin/bison' -y $@ How can i get autoconf to use bison? The problem with yacc is that you can't rename the output files

flex/bison rebuilding issue

Hi y'all, Attached is my Makefile.am. My problem is editing scanner.l or grammar.y doesn't trigger a rebuild of my whole project when *I think* it should... How do I set dependencies such that editing scanner.l or grammar.y will rebuild my whole parser? Thanks in advance, Reuben Makefile.am

Re: flex/bison rebuilding issue

On 09/09/2010 08:46 PM, Reuben Hawkins wrote: Hi y'all, Attached is my Makefile.am. My problem is editing scanner.l or grammar.y doesn't trigger a rebuild of my whole project when *I think* it should... How do I set dependencies such that editing scanner.l or grammar.y will rebuild my whole

Re: flex/bison rebuilding issue

will rebuild my whole parser? Hey there I use flex and bison alot with automake and yeah this isn't the right forum to be asking about this since Makefile.am's are handled by automake. But anyways if you edit your lexer, why do you need to rebuild your whole thing? Its just like editing any .c file

Re: bison and autotest

Hello Tys, * tys lefering wrote on Sat, Jan 23, 2010 at 07:43:53PM CET: GNU bison is using autotest with 'make maintainer-check' and that works fine. at failed test lines appear like: ./regression.at:941: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o dancer dancer.cc $LIBS is it possible to have

bison and autotest

Hi, GNU bison is using autotest with 'make maintainer-check' and that works fine. at failed test lines appear like: ./regression.at:941: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o dancer dancer.cc $LIBS is it possible to have the $CXX etc. expanded to 'g++' in the output or needs that change to autotest

Re: problem with automake and bison

According to Michael Walton on 1/10/2010 5:36 PM: I am using the autotools in combination with GNU Bison and Flex. In particular I am using the %glr directive in my bison file (parse.y). Everything works fine, except that when I run 'make', 'ylwrap' is invoked which runs 'bison -y -d

problem with automake and bison

I am using the autotools in combination with GNU Bison and Flex. In particular I am using the %glr directive in my bison file (parse.y). Everything works fine, except that when I run 'make', 'ylwrap' is invoked which runs 'bison -y -d' on 'parse.y' producing 'y.tab.h' and 'y.tab.c'. 'ylwrap

Re: 2.63b autotest vs. bison testsuite

Ralf Wildenhues Ralf.Wildenhues at gmx.de writes: I'm thinking of applying this series; any problems? The first (very minor) one that I see is that your log messages are not verbose enough for me to follow. For example, this: Addressed in the refactored series, shown below. I'll wait a

Re: 2.63b autotest vs. bison testsuite

Hi Eric, * Eric Blake wrote on Fri, Apr 24, 2009 at 04:54:21PM CEST: Ralf Wildenhues Ralf.Wildenhues at gmx.de writes: I'm thinking of applying this series; any problems? The first (very minor) one that I see is that your log messages are not verbose enough for me to follow. For

Re: 2.63b autotest vs. bison testsuite

Eric Blake ebb9 at byu.net writes: Of the three, only the last one presents any backwards incompatibilities, but as the bison testsuite recently went through some serious hoops to try to work around AT_CHECK failing to shell-escape macro contents, it seems like it is a true bug fix as opposed

Re: 2.63b autotest vs. bison testsuite

, rather than causing the test to fall apart). The third swaps the order of m4_expand and AS_ESCAPE in AT_CHECK, so that even characters inside macro expansions that need escaping are protected. Of the three, only the last one presents any backwards incompatibilities, but as the bison testsuite

Re: 2.63b autotest vs. bison testsuite

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 4/6/2009 11:14 AM: probably need to teach more of autotest about automake's recent addition of status 99 meaning hardfail (not even XFAIL can exempt it from making the overall testsuite report failure), but that is why

Re: 2.63b autotest vs. bison testsuite

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 4/6/2009 12:03 PM: Hi Eric, * Eric Blake wrote on Mon, Apr 06, 2009 at 07:14:36PM CEST: Ralf, do you think we should also add a 'parallel syntax check' test? Yes, definitely. And thanks for this patch and the

Re: 2.63b autotest vs. bison testsuite

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 4/6/2009 11:14 AM: Second, in the presence of a botched test (here, autotest botched it; but it is also conceivable that a developer could do likewise), the overall testsuite status was dependent on whether a previous

Re: 2.63b autotest vs. bison testsuite

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 4/9/2009 6:56 AM: However, this patch now makes an empty test fail instead of pass, which causes a regression in our testsuite. AT_SETUP([empty test]) AT_CLEANUP So I'm working on fixing that. Done as follows.

Re: Bison and flex target

this is meant to work. I am not a total guru with bison and flex yet so sorry if this is basic :) - -Phil Philip Herron wrote: Ralf Wildenhues wrote: Hello Philip, * Philip Herron wrote on Fri, Apr 03, 2009 at 02:51:50PM CEST: I am not sure if this is autoconf or automake. If you use Automake

Re: Bison and flex target

should change that and add a full working test. Contributions welcome. I see stuff on the gdb hack to redefine all the variables but not too sure how this is meant to work. I am not a total guru with bison and flex yet so sorry if this is basic :) I am not a total guru with bison and flex either

Re: 2.63b autotest vs. bison testsuite

* Eric Blake wrote on Mon, Apr 06, 2009 at 08:16:28PM CEST: http://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=abe172 Well, that patch was indeed the cause of a regression. However, bison was lucky that it was not using a shell comment, which is broken even in 2.63. Here's

2.63b autotest vs. bison testsuite

Found this while running the bison testsuite after upgrading to 2.63b: $ make check TESTSUITEFLAGS=56-57 ... ## -- ## ## GNU Bison 2.4.284-3583 test suite. ## ## -- ## Output file names. 56: Output file name

Re: 2.63b autotest vs. bison testsuite

Hi Eric, * Eric Blake wrote on Mon, Apr 06, 2009 at 07:14:36PM CEST: Ralf, do you think we should also add a 'parallel syntax check' test? Yes, definitely. And thanks for this patch and the testsuite size reduction! Cheers, Ralf

Bison and flex target

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey I am not sure if this is autoconf or automake. But i have a project and i have bison/yacc and lex/flex targets to compile. I see there is AC_PROG_YACC and AC_PROG_LEX to get the apropriate programs for the configure.ac. But how do you go about

Re: Bison and flex target

Hello Philip, * Philip Herron wrote on Fri, Apr 03, 2009 at 02:51:50PM CEST: I am not sure if this is autoconf or automake. If you use Automake, then this is an Automake question. :-) I see there is AC_PROG_YACC and AC_PROG_LEX to get the apropriate programs for the configure.ac. But how do

Re: Bison and flex target

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: Hello Philip, * Philip Herron wrote on Fri, Apr 03, 2009 at 02:51:50PM CEST: I am not sure if this is autoconf or automake. If you use Automake, then this is an Automake question. :-) I see there is AC_PROG_YACC and

Re: m4sugar and m4 1.6, bison

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paolo Bonzini on 7/31/2008 2:05 AM: | undocumented macro. At any rate, updating bison to newer m4sugar | requires | this interface, unless we rewrite bison to not need prepending. | | FYI, | | ~/devel/bison/data bonzinip$ grep

Re: m4sugar and m4 1.6, bison

Eric Blake ebb9 at byu.net writes: I'm committing these two patches. The first works around warnings caused by dereferencing undefined macros (available on m4's master branch for some time now, and recently backported to branch-1.6): $ m4 -I lib m4sugar/m4sugar.m4

Re: m4sugar and m4 1.6, bison

/argv_ref Nice. It turns out that 'git grep m4_prepend' turns up nothing of interest in bison.git, so apparantly, bison is not using it anymore (as of 2006-01-03, http://git.savannah.gnu.org/gitweb/?p=bison.git;a=commitdiff;h=8f7e3cf). Should I go ahead and revert my addition of m4_prepend

Re: m4sugar and m4 1.6, bison

Eric Blake ebb9 at byu.net writes: The second patch is for something I discovered when trying to fix bison's usage of m4sugar [1]. Bison forked m4sugar somewhere in between autoconf 2.59 and 2.59c, then added m4_prepend, and skips the m4_PACKAGE_* macros defined in autoconf's

Re: m4sugar and m4 1.6, bison

* Eric Blake wrote on Sun, Jul 13, 2008 at 03:18:37PM CEST: According to Ralf Wildenhues on 7/12/2008 12:39 AM: | * Ralf Wildenhues wrote on Sat, Jul 12, 2008 at 08:11:55AM CEST: | # m4_make_macro_name(STRING) | # Turn all characters not fitting to be a macro name into '_'. |

Re: m4sugar and m4 1.6, bison

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 7/14/2008 1:26 PM: | But there is still the matter of how to remove all | the stale macros if the key being appended to is redefined as empty. | | ... are certainly enough of a churn to require that such an improved |

Re: m4sugar and m4 1.6, bison

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 7/12/2008 12:39 AM: | * Ralf Wildenhues wrote on Sat, Jul 12, 2008 at 08:11:55AM CEST: | So then here's a first prototype for fast m4_append_uniq, completely | untested, and would probably need some more-unique

Re: m4sugar and m4 1.6, bison

to use good algorithms by | only providing those interfaces...) Maybe the compromise would be provide it in m4sugar.m4, but remove mention of it in NEWS and autoconf.texi, leaving bison to use it as an undocumented macro. At any rate, updating bison to newer m4sugar requires this interface

Re: m4sugar and m4 1.6, bison

* Ralf Wildenhues wrote on Sat, Jul 12, 2008 at 08:11:55AM CEST: So then here's a first prototype for fast m4_append_uniq, completely untested, and would probably need some more-unique separator after $1 in the definition of m4_key. I'll blame it on lack of coffee... #

m4sugar and m4 1.6, bison

by m4 rather than having to write our own wrappers that use m4_ifdef and m4_warn. The second patch is for something I discovered when trying to fix bison's usage of m4sugar [1]. Bison forked m4sugar somewhere in between autoconf 2.59 and 2.59c, then added m4_prepend, and skips the m4_PACKAGE_

Re: m4sugar and m4 1.6, bison

Hi Eric, * Eric Blake wrote on Fri, Jul 11, 2008 at 07:54:19PM CEST: Bison forked m4sugar somewhere in between autoconf 2.59 and 2.59c, then added m4_prepend, I personally think it's a shame to add known-suboptimal interfaces like m4_prepend at all, but oh well. (I think in a better world

Re: AC_PATH_PROGS_FEATURE_CHECK [was: Bug in gnulib-tools prevents bison from bootstrapping]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Noah Misch on 9/5/2007 2:19 PM: Improve M4 path searching during configure. * lib/autoconf/programs.m4 (AC_PATH_PROGS_FEATURE_CHECK): New macro. ... The parts related to the above look ok Committed the rest of this

Re: AC_PATH_PROGS_FEATURE_CHECK [was: Bug in gnulib-tools prevents bison from bootstrapping]

On Sat, Sep 01, 2007 at 09:35:28PM -0600, Eric Blake wrote: 2007-09-01 Eric Blake [EMAIL PROTECTED] Improve M4 path searching during configure. * lib/autoconf/programs.m4 (AC_PATH_PROGS_FEATURE_CHECK): New macro. (_AC_PATH_PROG_FEATURE_CHECK): Rename...

Re: AC_PATH_PROGS_FEATURE_CHECK [was: Bug in gnulib-tools prevents bison from bootstrapping]

in context: http://www.nabble.com/Re%3A-Bug-in-gnulib-tools-prevents-bison-from-bootstrapping-tf4360008.html#a12510544 Sent from the Gnu - Autoconf - Patches mailing list archive at Nabble.com.

Re: AC_PATH_PROGS_FEATURE_CHECK [was: Bug in gnulib-tools prevents bison from bootstrapping]

On Wed, Sep 05, 2007 at 01:45:49PM -0700, Eric Blake-1 wrote: [EMAIL PROTECTED] AC_CHECK_PROG (@var{variable}, @var{prog-to-check-for}, @var{value-if-found}, @ovar{value-if-not-found}, @ovar{path}, @ovar{reject}) [EMAIL PROTECTED] AC_CHECK_PROG (@var{variable}, @var{prog-to-check-for},

Re: Bug in gnulib-tools prevents bison from bootstrapping

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [reviving an old thread, replies can probably drop bug-autoconf] According to Noah Misch on 6/23/2007 8:54 PM: On 23 Jun 2007, at 06:25, Eric Blake wrote: My system has a /usr/bison/m4 and a /usr/bin/gm4, but no /usr/local/bin/gm4, because later

Re: Bug in gnulib-tools prevents bison from bootstrapping

On Fri, Aug 31, 2007 at 06:50:07AM -0600, Eric Blake wrote: In other words, during configuration, autoconf finds the first program on your PATH named gm4, gnum4, and then m4, which also meets the minimum requirements of m4 1.4.5 or later. The attached patch implements the above algorithm.

Re: Bug in gnulib-tools prevents bison from bootstrapping

-in-gnulib-tools-prevents-bison-from-bootstrapping-tf4360008.html#a12430388 Sent from the Gnu - Autoconf - Patches mailing list archive at Nabble.com.

Re: Bug in gnulib-tools prevents bison from bootstrapping

On Fri, Aug 31, 2007 at 10:03:09AM -0700, Eric Blake-1 wrote: I see no AC_SUBST(M4) in your patch, though. The AC_SUBST is implicit, via the AC_ARG_VAR. So I only needed M4=$ac_cv_path_M4 after the program check. Ah, yes. The only reason for MSG in my suggestion is because of the tie-in

Re: Bug in gnulib-tools prevents bison from bootstrapping

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [reviving an old thread, replies can probably drop bug-autoconf] According to Noah Misch on 6/23/2007 8:54 PM: On 23 Jun 2007, at 06:25, Eric Blake wrote: My system has a /usr/bison/m4 and a /usr/bin/gm4, but no /usr/local/bin/gm4, because later

Re: Bug in gnulib-tools prevents bison from bootstrapping

On 23 Jun 2007, at 06:25, Eric Blake wrote: If you reconfigured autoconf after installing a newer GNU m4, and autoconf did not find the right m4, then that is a bug in autoconf, and should be dealt with there. Right. Since it was experienced by the developers on the Bug-Bison list, I

Re: Bug in gnulib-tools prevents bison from bootstrapping

maintainers, I am not sure the above explanation holds up, because I think I had a /usr/local/bin/m4 long before I had a /usr/local/bin/autoconf, and others on the Bison list experienced the same problem, but could not find its origin. would be either reconfiguring and reinstalling autoconf after

Re: Bison configuration is incorrect

On 10/24/06, Paulo J. Matos [EMAIL PROTECTED] wrote: For some unknown reason when I use AC_PROG_YACC, I get when I run configure: checking for bison... byacc -d The reason is not unknown anymore and it was my fault which copied a bunch of bash configuration to my .bashrc and one of the lines

Bison configuration is incorrect

Hi all, For some unknown reason when I use AC_PROG_YACC, I get when I run configure: checking for bison... byacc -d but: $ make (...) make[2]: Entering directory `/home/pmatos/software/trainer-build/src' byacc -d -d ../../dolphin/trainer/src/foo-parser.yy make[2]: byacc: Command not found make

Re: Bison 2.3

Akim == Akim Demaille [EMAIL PROTECTED] writes: OK. I've suggested splitting the autotest test suite before. Let's look at that idea again sometime later (one file per test, and source them for execution from the main test suite script), it's bound to give both execution time

Re: Bison 2.3

OK. I've suggested splitting the autotest test suite before. Let's look at that idea again sometime later (one file per test, and source them for execution from the main test suite script), it's bound to give both execution time improvements and portability improvements. Using functions should

Re: Bison 2.3

* H.Merijn Brand wrote on Wed, Jun 07, 2006 at 09:28:16PM CEST: On Wed, 7 Jun 2006 20:38:38 +0200, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Paul Eggert wrote on Wed, Jun 07, 2006 at 08:27:17PM CEST: H.Merijn Brand [EMAIL PROTECTED] writes: It's a long-known fact that the AIX /bin/sh

Re: bison generated files

Hi, On Tue, May 23, 2006 at 07:51:01PM -0400, Bob Rossi wrote: Does 'make dist' automatically include them in the distro though? supposing you are using Automake, yes. Stepan ___ Autoconf mailing list Autoconf@gnu.org

Re: bison generated files

Does 'make dist' automatically include them in the distro though? supposing you are using Automake, yes. And if you don't use Automake, the answer is `maybe'. groff doesn't use Automake, but it's `make dist' *does* ensure that all bison and texinfo generated files go into the tarball; (none

Re: bison generated files

On Mon, May 22, 2006 at 02:13:26PM -0400, Bob Rossi wrote: Hi, Does anyone know if bison generated files typically get checked into the source repository, and build system the same way flex generated files are? That way, other developers or users do not need bison installed if they do

Re: bison generated files

Bob Rossi [EMAIL PROTECTED] writes: Does anyone know if bison generated files typically get checked into the source repository, and build system the same way flex generated files are? That way, other developers or users do not need bison installed if they do not change the bison grammar files

Re: bison generated files

On Tue, May 23, 2006 at 04:48:56PM -0700, Paul Eggert wrote: Bob Rossi [EMAIL PROTECTED] writes: Does anyone know if bison generated files typically get checked into the source repository, and build system the same way flex generated files are? That way, other developers or users do

Re: bison generated files

Hi Bob, * Bob Rossi wrote on Wed, May 24, 2006 at 01:51:01AM CEST: Does 'make dist' automatically include them in the distro though? Yes. info Automake Yacc and Lex Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org

bison generated files

Hi, Does anyone know if bison generated files typically get checked into the source repository, and build system the same way flex generated files are? That way, other developers or users do not need bison installed if they do not change the bison grammar files. If so, how do I do this? Thanks

Re: m4_map_sep bug (introduced by 2005-06-06 Autoconf patch) breaks Bison

Hello, On Wed, Oct 05, 2005 at 04:20:10PM -0700, Paul Eggert wrote: In http://lists.gnu.org/archive/html/bug-bison/2005-10/msg4.html John P. Hartmann [EMAIL PROTECTED] writes: http://lists.gnu.org/archive/html/autoconf-patches/2005-06/txtRXb8U1rojj.txt ... The change to m4sugar

m4_map_sep bug (introduced by 2005-06-06 Autoconf patch) breaks Bison

In http://lists.gnu.org/archive/html/bug-bison/2005-10/msg4.html John P. Hartmann [EMAIL PROTECTED] writes: http://lists.gnu.org/archive/html/autoconf-patches/2005-06/txtRXb8U1rojj.txt ... The change to m4sugar generates a spurious semicolon before the function body (opening {) when

Your message to Bison-patches awaits moderator approval

Your mail to 'Bison-patches' with the subject =?GB2312?B?1tC5+qOouePW3aOpxvuztdPrxeS8/tPDxrez9r/avbvS17vh?= Is being held until the list moderator can review it for approval. The reason it is being held: Message has a suspicious header Either the message will get posted to the list

Re: Functions / satellite scripts (Was: bison-1.29c 'configure' problems on Solaris 8.)

Paul Eggert wrote: I think this idea is a blind alley. If we want to use modern shell features, then we should go ahead and require the configure user to have a modern shell. That's much simpler. We've already started down that path with the LINENO changes. Wouldn't this be solvable

Re: Functions / satellite scripts (Was: bison-1.29c 'configure' problems on Solaris 8.)

On Mon, Oct 22, 2001 at 08:18:13AM -0400, Earnie Boyd wrote: : Paul Eggert wrote: : I think this idea is a blind alley. If we want to use modern shell : features, then we should go ahead and require the configure user to : have a modern shell. That's much simpler. We've already started down

Re: Functions / satellite scripts (Was: bison-1.29c 'configure' problems on Solaris 8.)

Lars J. Aas wrote: On Mon, Oct 22, 2001 at 08:18:13AM -0400, Earnie Boyd wrote: : Paul Eggert wrote: : I think this idea is a blind alley. If we want to use modern shell : features, then we should go ahead and require the configure user to : have a modern shell. That's much simpler.

Functions / sattelite scripts (Was: bison-1.29c 'configure' problems on Solaris 8.)

On Fri, Oct 19, 2001 at 06:00:38PM +0200, Akim Demaille wrote: : Gary == Gary V Vaughan [EMAIL PROTECTED] writes: : Gary As far as shell functions are concerned, it seems to me that : Gary m4sh could provide shell function wrapper macros which expand to : Gary a function/function call if that is

Re: bison-1.29c 'configure' problems on Solaris 8.

Gary == Gary V Vaughan [EMAIL PROTECTED] writes: Gary As far as shell functions are concerned, it seems to me that Gary m4sh could provide shell function wrapper macros which expand to Gary a function/function call if that is supported by the shell, or Gary else an inline function if not...

Re: bison-1.29c 'configure' problems on Solaris 8.

On Fri, Oct 19, 2001 at 06:00:38PM +0200, Akim Demaille wrote: Gary == Gary V Vaughan [EMAIL PROTECTED] writes: Gary As far as shell functions are concerned, it seems to me that Gary m4sh could provide shell function wrapper macros which expand to Gary a function/function call if that is

Re: bison-1.29c 'configure' problems on Solaris 8.

Paul == Paul Eggert [EMAIL PROTECTED] writes: From: Akim Demaille [EMAIL PROTECTED] Date: 04 Oct 2001 17:31:18 +0200 First let's find a portable LINENO, *then* move to another shell. Paul But the attempt to find a portable LINENO is not cost-free. Paul It is broken now, and it will take

Re: bison-1.29c 'configure' problems on Solaris 8.

On Fri, Oct 05, 2001 at 10:56:04AM +0200, Akim Demaille wrote: People, the question is: If we look for a reasonable shell and re-exec configure once we found one, are you OK with keeping $LINENO used in configure, even if the shell does not treat $LINENO

Re: bison-1.29c 'configure' problems on Solaris 8.

Hi, Akim! People, the question is: If we look for a reasonable shell and re-exec configure once we found one, are you OK with keeping $LINENO used in configure, even if the shell does not treat $LINENO specially? *And*, keep in mind the decision involves M4sh too

Re: bison-1.29c 'configure' problems on Solaris 8.

From: Akim Demaille [EMAIL PROTECTED] Date: 05 Oct 2001 10:56:04 +0200 So am I understanding that LINENO is a POSIX feature? Yes. The current implementation in CVS Autoconf might be broken, but really, I fail to understand what makes you fear the LINENO stuff that much. Why do you say