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

I propose the following patch to fix Automake's prototype of yyerror. Cheers! commit 38242845a146d6438e3f884100aa3e670142e393 Author: Akim Demaille Date: Sat Sep 11 09:39:00 2021 +0200 tests: let yacc's yyerror take its argument as a const string Some of yacc error me

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

Hi Sam, > Le 10 sept. 2021 à 18:51, Sam James a écrit : > > Thanks your work on this! Brief comments on version changes: > >> diff --git a/src/parse-gram.c b/src/parse-gram.c >> index 95fe43e0..3bc44dbd 100644 >> --- a/src/parse-gram.c >> +++ b/src/parse-gram.c >> @@ -1,4 +1,4 @@ >> -/* A Bison

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

Hi all, > Le 9 sept. 2021 à 07:10, Akim Demaille a écrit : > > Hi! > >> Le 9 sept. 2021 à 00:32, Paul Eggert a écrit : >> >> On 9/8/21 2:18 PM, Karl Berry wrote: >>> Just an idea that I don't expect you to adopt, but just to mention -- >>

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

Hi! > Le 9 sept. 2021 à 00:32, Paul Eggert a écrit : > > On 9/8/21 2:18 PM, Karl Berry wrote: >> Just an idea that I don't expect you to adopt, but just to mention -- >> you could only institute the breaking change if POSIXLY_CORRECT. That's >> why POSIXLY_CORRECT exists. -k > > I like this id

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

Hi Paul, Thanks for the quick answer. > Le 8 sept. 2021 à 08:33, Paul Eggert a écrit : > > On 9/7/21 10:31 PM, Akim Demaille wrote: >> However, I don't see a published version of the POSIX Yacc "specs" that >> includes these changes. > > Th

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

Hi Kiyoshi, > Le 8 sept. 2021 à 04:11, Kiyoshi KANAZAWA a > écrit : > > Hello, > > Installed bison-3.8, but I'm afraid it is has bug or side effect to > flex-2.6.4 & automake-1.16.4. > > $ uname -a > SunOS hidden 5.11 11.3 i86pc i386 i86pc > > $ gcc --version > gcc (GCC) 10.3.0 > > After i

bug#24507: noinst_PYTHON breaks uninstall of Python files

Hi Friends! > $ cat configure.ac > AC_INIT([foo], [1.0]) > AM_INIT_AUTOMAKE([1.15 foreign]) > AM_PATH_PYTHON > AC_OUTPUT([Makefile]) > $ cat Makefile.am > noinst_PYTHON = foo.py > python_PYTHON = bar.py > $ autoreconf -fi > $ grep am__pep3147_tweak Makefile.in > py_files_pep3147=`echo "$$p

bug#16527: 1.14: (nodist_)python_PYTHON does not behave as bin_SCRIPTS

Hi! « all » correctly depends on (nodist_)bin_SCRIPTS: if some script is generated/compiled, then « make » makes it. I have this piece of Python code which is AC_CONFIG_FILES’d, so it is generated by config.status. Plain « make » does not update/create it, I have to add an explicit dependency.

bug#16302: 1.14.1: check-TESTS is not lazy enough

Le 31 déc. 2013 à 00:11, Stefano Lattarini a écrit : > Hi Akim. Hi! Thanks for the quick answer. >> At first sight it seems that it should be guarded by ‘test -n $$redo_log’. >> > Indeed. > >> This is *really* costly, I’d be happy to have nice workarounds. >> > Or eve better, to fix the b

bug#16302: 1.14.1: check-TESTS is not lazy enough

Hi all, I have this piece of software with several APIs, organized in clear layers. Building the whole package is costly, especially because of the top-level layers (dozens of binaries), and the whole test suite is even costlier (because it requires to build the whole set of binaries, and then it

bug#14991: distcheck passes --prefix to configure before *DISTCHECK_CONFIGURE_FLAGS

Hi Stefano! Le 30 oct. 2013 à 23:02, Stefano Lattarini a écrit : > I've fixed the issue with the two attached patches, that will appear > in Automake 1.14.1 (someday when I'll actually get around to release > it ;-). I will wait some time before pushing the patches out, so a > review is welcom

bug#14991: distcheck passes --prefix to configure before *DISTCHECK_CONFIGURE_FLAGS

Hi! Admittedly, what prompts this report is arguably a bug in a package: It passes _all_ the configure flags to AM_DISTCHECK_CONFIGURE_FLAGS. Not a bright idea I guess, but simple. Unfortunately distcheck reads: # This target untars the dist file and tries a VPATH configuration. Then # it guar

bug#13351: [Automake-NG] bug#13351: [IMPORTANT] Dropping support for split '.info' files in mainline Automake

Le 7 janv. 2013 à 20:30, Stefano Lattarini a écrit : > Reference: > > > On 01/04/2013 05:43 PM, Stefano Lattarini wrote: >> Hi Thien-Thi, thanks for the feedback. >> >> On 01/04/2013 03:07 PM, Thien-Thi Nguyen wrote: >>> () Stefano Lattarin

bug#12320: bison 2.6.2 contains stale info files

(Karl and Jim, see below about gendocs, Stefano, see below about Automake-OG). Hi Peter, hi friends, Le 6 août 2012 à 11:37, Peter Breitenlohner a écrit : > Hi, > > the distributed bison-2.6.2 tarball contains the two stale files > doc/bison.info-{1,2} from 2.6.1-dirty, and their existence in t

bug#11814: The test logs lost their title

It seems that in recent changes, the test logs have lost their title, which included the exit status. Now, reading a log, one can no longer know how the test exited.

bug#11419: [PATCH] yacc, lex: new 'no-ylwrap' option to prevent use of the 'ylwrap' script

(wow, _that_ is quite a list of CCs. Hi mum!) Hi Eric, Le 26 juin 2012 à 18:18, Eric Blake a écrit : > Eek - that just shows that I'm really behind on reading my email. Thou shalt be punished. Beware of my wrath. > Just from reading this summary, the idea of improving AC_PROG_LEX and > AC_PR

bug#11419: [PATCH] yacc, lex: new 'no-ylwrap' option to prevent use of the 'ylwrap' script

Le 26 juin 2012 à 17:35, Stefano Lattarini a écrit : > This is probably a better idea, yes. This could probably be done by > enhancing AM_PROG_LEX and defining a similar new AM_PROG_YACC macro. > Or better again, it could be done directly in AC_PROG_LEX and > AC_PROG_YACC, so that we could just

bug#11419: [PATCH] yacc, lex: new 'no-ylwrap' option to prevent use of the 'ylwrap' script

Hi Stefano, Thanks for this! Le 25 juin 2012 à 16:01, Stefano Lattarini a écrit : > When used with good yacc and lex implementations, like Flex and GNU Bison, > the 'ylwarp' ylwrap > script (meant to work around the deficiencies of older or > inferior yacc and lex implementations) creates far

bug#11419: ylwrap does not rename y.tab.h in y.tab.c

Hi all, Le 25 juin 2012 à 11:30, Stefano Lattarini a écrit : >> Well, I guess I must step back. I installed what follows >> in maint. >> > Sigh, advancement on Bison kept back by the fact that Automake used to > bend over backwards to support inferior yacc implementation that today > hardly any

bug#11419: Get rid of ylwrap, and simplify yacc/lex rules (was: Re: FYI: maint: fix the generation of the synclines for bison's parser)

Le 6 mai 2012 à 12:38, Stefano Lattarini a écrit : > Severity: wishlist > > [Adding bug-automake in CC:] > > Hi Akim. > > On 05/06/2012 11:20 AM, Akim Demaille wrote: >> This is taken from master. I work with a VPATH build, and the >> generated synclines ar

bug#11287: Various issues with the test suite framework

Le 24 avr. 2012 à 11:42, Stefano Lattarini a écrit : > On 04/20/2012 01:13 PM, Akim Demaille wrote: >> Hi! >> > Hi Akim, sorry for the delay. Hi Stefano, No worries. >> I have seen that check-html will be removed, or rather moved >> into the contrib pa

bug#11287: Various issues with the test suite framework

Hi! I have seen that check-html will be removed, or rather moved into the contrib part, but there are a few issues: - the target is not declared recursive, so one has to write the bouncing target herself. - because of that, the "naive" implementation of check-html that just bounces the right d

bug#10852: VPATH builds cannot recover from missing parser header

Le 20 févr. 2012 à 14:58, Stefano Lattarini a écrit : >> Also, why two "if"? >> > For the sake of "make -n": at least GNU make and Solaris make execute > recipes containing the $(MAKE) string even when they are running in dry > mode; so if we didn't break the recipe above in two invocations, the

bug#10852: VPATH builds cannot recover from missing parser header

Le 23 févr. 2012 à 10:43, Stefano Lattarini a écrit : >> src/parse-gram.h: src/parse-gram.c >> test -f $@ || rm -f src/parse-gram.c >> test -f $@ || $(MAKE) $(AM_MAKEFLAGS) src/parse-gram.c >> > This seems nicer. Care to write a patch to implement this simplification > (here and for o

bug#10852: VPATH builds cannot recover from missing parser header

hi Stefano, Hello World!\n Le 20 févr. 2012 à 14:58, Stefano Lattarini a écrit : > Hi Akim. > > On 02/20/2012 02:24 PM, Akim Demaille wrote: >>> src/parse-gram.h: src/parse-gram.c >>> @if test ! -f $@; then rm -f src/parse-gram.c; else :; fi >>&g

bug#10852: VPATH builds cannot recover from missing parser header

Le 20 févr. 2012 à 15:23, Akim Demaille a écrit : >> But the test is wrong, because it checks that the Yacc-generated .h and .c >> files are placed in the $srcdir, while we expect them to be placed in the >> $builddir. Do the tests added by your patch work for you? They do

bug#10852: VPATH builds cannot recover from missing parser header

Le 20 févr. 2012 à 14:58, Stefano Lattarini a écrit : > Hi Akim. Hi Stefano, Thanks for the quick answer! > The following patch extends a test which is aimed at checking >> >> this, but does it in a non-vpath build :) >> > But the test is wrong, because it checks that the Yacc-generated .h a

bug#10852: VPATH builds cannot recover from missing parser header

I am having problems in Bison (current master) to recover from a lost parse-gram.h, generated from parse-gram.y with regular Automake (1.11.3) handling: > AM_YFLAGS = -d -v --warnings=all,error --report=all > > src_bison_SOURCES = \ > ... > src/output.h

bug#10825: Better bison support in Automake (was: Re: FYI: master: calc++: rely on Automake)

Le 16 févr. 2012 à 11:21, Stefano Lattarini a écrit : > Hi Akim. Hi! > Thanks, fixed (see attached patch). > >> But maybe automake no longer needs this? >> > It still need it; without that, no header file will be generated from > the '.y' files (this is a feature, not a bug). > >> If it does

bug#9822: AMTAR not used

Hi all, My apologies if this has already been discussed. I too have been hit by the fact that Tar on OS X tries to preserve special features of files in "hidden" files (a thread about this started here: http://lists.gnu.org/archive/html/automake/2011-03/msg00127.html, and seems to end here:

bug#7441: 1.11.1: Emacs files in subdirs

Le 19 nov. 2010 à 11:10, Ralf Wildenhues a écrit : > Hi Akim, Hi Ralf, > Yes. I asked the necessary questions a while ago: > > > answers are still needed. Sorry for the noise :( Thanks for looking into it!

bug#7441: 1.11.1: Emacs files in subdirs

Hi all, When passing _LISP files with a path, Automake produces schizophrenic Makefiles that expects the elc files to have the same path too, but produces elc files in `.'. Makefile.am dist_lisp_LISP = build-aux/rebox.el build-aux/tiger.el build-aux/leopard.el Makefile.in LISP = $(

Re: dist_noinst_MANS

Le 13 oct. 10 à 20:12, Ralf Wildenhues a écrit : Hi Akim, thanks for the feature request, and sorry for the delay. No problem, there's no hurry! * Akim Demaille wrote on Fri, Sep 24, 2010 at 01:44:34PM CEST: Currently Automake accepts happily such a variable name, but it does not u

Re: Missing *-local hooking

Le 20 nov. 07 à 22:04, Ralf Wildenhues a écrit : Hi Akim, * Akim Demaille wrote on Mon, Nov 19, 2007 at 03:25:51PM CET: Automake does not notice the use of *-local targets when defined together: Go ahead if you'd like to commit this as a currently-XFAILing test, but even better if yo

Missing *-local hooking

Automake does not notice the use of *-local targets when defined together: diff --git a/tests/all.test b/tests/all.test index e9ffb70..1d82525 100755 --- a/tests/all.test +++ b/tests/all.test @@ -1,5 +1,5 @@ #! /bin/sh -# Copyright (C) 1999, 2001, 2002 Free Software Foundation, Inc. +# Copyrigh

Re: Multiply distributed files

>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: Oops, sorry for the delays, I hadn't noticed you had answered. >>> "AD" == Akim Demaille <[EMAIL PROTECTED]> writes: AD> So the "dist" immediately below is ex

Multiply distributed files

Hi, I have a Makefile snippet which is part of a directory which I ship as is (EXTRA_DIST) in my tarballs (something comparable to gnulib if you wish). I include this Makefile snippet elsewhere, and as a result, Automake will distribute it. Hence this file is "listed" twice to be shipped. In s

Re: Info files--declaration and distribution

>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes: > Akim, would you agree with this change to the comment? Sure.