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 messages
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
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 --
>>&
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
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.
>
> The nex
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
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
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.
Le 31 déc. 2013 à 00:11, Stefano Lattarini stefano.lattar...@gmail.com 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
Le 31 déc. 2013 à 00:11, Stefano Lattarini stefano.lattar...@gmail.com 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
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
Hi Stefano!
Le 30 oct. 2013 à 23:02, Stefano Lattarini stefano.lattar...@gmail.com 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
Hi Stefano!
Le 30 oct. 2013 à 23:02, Stefano Lattarini stefano.lattar...@gmail.com 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
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
Le 13 mai 2013 à 20:08, Stefano Lattarini stefano.lattar...@gmail.com a écrit
:
Hi Akim, glad to read again from you :-)
Hi Stefano!
I'm happy both to read from you, and to see Automake NG is
still alive. Sleeping beauty, awaiting for a kiss from her Stefano.
BTW, Akim, would you like me
Le 8 mai 2013 à 01:12, Stefano Lattarini stefano.lattar...@gmail.com a écrit :
+# Shell code that determines whether the current make instance is
No longer shell code.
+# running with a given letter option (e.g., -k, -n) that takes
+# no argument. It is either 'true' or 'false', so that it
Le 1 févr. 2013 à 10:35, Stefano Lattarini stefano.lattar...@gmail.com a
écrit :
So, is anyone using or playing with Automake-NG, or at least
contemplating the idea to do so in the short term? Or should
we just let the project die?
I subscribe to all the good opinions about NG that have
On Sat, Jan 12, 2013 at 8:18 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
tags 11419 wontfix
close 11419
thanks
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11419
The improvements to the ylwrap script contributed by Akim in the 1.12.x
and 1.13 releases have fixed
Le 1 févr. 2013 à 10:35, Stefano Lattarini stefano.lattar...@gmail.com a
écrit :
So, is anyone using or playing with Automake-NG, or at least
contemplating the idea to do so in the short term? Or should
we just let the project die?
I subscribe to all the good opinions about NG that have
Le 7 janv. 2013 à 20:30, Stefano Lattarini stefano.lattar...@gmail.com a
écrit :
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13351
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:
()
Le 7 janv. 2013 à 20:30, Stefano Lattarini stefano.lattar...@gmail.com a
écrit :
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13351
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:
()
The first patch enhances a test to exhibit a failure that the second
addresses.
Akim Demaille (2):
tests: strengthen the ylwrap tests
ylwrap: various fixes
NEWS | 18 ++
lib/ylwrap| 27 ++-
t/yacc-d-basic.sh | 51
* lib/ylwrap (guard): Properly honor $1.
Keep a single _ instead of several.
(RENAME_sed): new.
Use it.
---
NEWS | 18 ++
lib/ylwrap | 27 ++-
2 files changed, 36 insertions(+), 9 deletions(-)
diff --git a/NEWS b/NEWS
index 7a230ef..482216c 100644
* t/yacc-d-basic.sh: Comment changes.
(generated): New.
Use it to factor various tests.
Check that Y_TAB_H is not issued.
---
t/yacc-d-basic.sh | 51 +--
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/t/yacc-d-basic.sh
Le 21 déc. 2012 à 17:44, Stefano Lattarini stefano.lattar...@gmail.com a
écrit :
Hi Akim.
Hi!
On 12/19/2012 02:55 PM, Akim Demaille wrote:
* lib/ylwrap (guard): Properly honor $1.
I fear this is the ChangLog style that I dislike: just reporting the
what of the change, without the why
Le 21 déc. 2012 à 18:43, Stefano Lattarini stefano.lattar...@gmail.com a
écrit :
On 12/21/2012 06:31 PM, Akim Demaille wrote:
Since you have a very good
explanation of such a why (as seen in the NEWS file), would you
mind reporting it (at least in an abridged form) in the commit message
Le 19 sept. 2012 à 21:49, Stefano Lattarini a écrit :
Well, if the user calls make all in the recipe for a $(BUILT_SOURCES),
he will still experience a fork bomb, even after this patch -- but that
is the case also for mainline Automake, so no regression here. On the
other hand, before this
Le 16 sept. 2012 à 20:21, Stefano Lattarini a écrit :
Hi Akim.
On 09/16/2012 03:48 PM, Akim Demaille wrote:
Le 11 sept. 2012 à 16:49, Stefano Lattarini a écrit :
Due to how the handling of $(BUILT_SOURCES) was implemented in Automake-NG,
a recursive make call in the recipe of any
Hi!
Le 8 août 2012 à 12:40, Stefano Lattarini a écrit :
On 08/08/2012 12:36 PM, Stefano Lattarini wrote:
Prefer using GNU make built-in '$(notdir)' instead. This change doesn't
offer any serious simplification, but is just a step in the general
direction of moving more non-trivial
Le 11 août 2012 à 11:51, Stefano Lattarini a écrit :
For better parallelism in make dist. This was already the case
for mainline Automake, but our recent changes to the dist-related
code in Automake-NG had broken that invariant.
* automake.in (handle_dist): Here, use 'unshift' rather than
Le 11 août 2012 à 20:17, Stefano Lattarini a écrit :
+ # Append to dirs, not files, because the files in '$*clean' can also
+ # contain any directory created by makeinfo --html, as well as the
+ # '*.t2d' and '*.t2p' directories used by texi2dvi and texi2pdf.
Can't we use only t2d?
(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 the
Le 2 août 2012 à 11:47, Stefano Lattarini a écrit :
Instead of copying their contents in each output Makefile.
* automake.in (verbatim): Instead of copying the given Makefile fragment
in the output makefile, copy it in the '.mk' subdirectory of the top-level
source directory (i.e., the one
Le 2 août 2012 à 16:18, Stefano Lattarini a écrit :
Why hide it? It will show anyway. IMHO, this should be
build-aux/automake/ or build-aux/mk.
I guess you use build-aux to mean the directory specified by
AC_CONFIG_AUX_DIR, right?
Yes :)
If yes, I agree this would offer more
clarity
Le 2 août 2012 à 19:35, Stefano Lattarini a écrit :
Here it is (see attachment). OK?
It is. Yet I realize that this goes against what we talked about a while ago.
I personally structure my build-aux directories. I have build-aux/m4,
build-aux/make (which contains *.mk that I include in
Le 31 juil. 2012 à 18:05, Stefano Lattarini a écrit :
This make it clear and manifest the fact that they are not parsed
makes and I'm not sure if manifest is a name or a verb here :)
Adjust according to your grammar.
Or maybe Make clear and manifest that they…?
like the other '*.am' files
Le 31 juil. 2012 à 18:24, Stefano Lattarini a écrit :
Superseded in all its current uses by 'verbatim'.
* automake.in (almost_verbatim): Delete.
This closes a whole set of refactoring changes. Congrats!
Le 1 août 2012 à 12:49, Stefano Lattarini a écrit :
+# Test to make sure subdirs in EXTRA_DIST work.
+# Also tests to make sure *srcdir is properly handled.
+# Also test the situation when the list of distributed files contains
where?
Or Also test when the list…
# a directory and a file
Le 30 juil. 2012 à 18:45, Stefano Lattarini a écrit :
This will allow us to actually put such fragments in distributed
files, and then include them *at make runtime*, instead of copying
their contents in every single makefile (as is done now, a legacy
from mainline Automake).
*
Le 30 juil. 2012 à 19:03, Stefano Lattarini a écrit :
* automake.in (verbatim): If used in empty context, continue to act
as before, and append the read makefile fragment to '$output_verbatim'.
But if used in scalar or list context, return it instead.
A similar comment in the code might be
Le 30 juil. 2012 à 19:20, Stefano Lattarini a écrit :
* lib/am/clean.am: Here. So that they will be visible also in
the generated Makefiles.
ok.
Le 30 juil. 2012 à 20:20, Stefano Lattarini a écrit :
This is preferable to having to use the '%MAKEFILE%', '%MAKEFILE-IN%'
and '%MAKEFILE-AM%' transforms in several places, and will enable us
to do more sweeping refactorings in the future.
* automake.in (generate_makefile): Define new
Le 30 juil. 2012 à 21:04, Stefano Lattarini a écrit :
* automake.in ($am_relative_dir): Delete, it was only used once ...
(generate_makefile): ... in here, so it's simpler to inline its
expansion.
(initialize_per_input): Don't reset the deleted variable.
ok.
Le 30 juil. 2012 à 22:10, Stefano Lattarini a écrit :
* lib/am/am-dir.am (am--distclean-amdir): Delete this phony rule and
the 'distclean-am' dependency on it ...
(am__distclean_dirs): ... simply append $(am.dir) to this instead.
OK.
Le 31 juil. 2012 à 00:56, Stefano Lattarini a écrit :
More precisely, do these renames:
am__mostlyclean_files - am.clean.mostly.f
am__clean_files- am.clean.normal.f
am__distclean_files- am.clean.dist.f
am__maintclean_files - am.clean.maint.f
am__mostlyclean_dirs
Le 28 juil. 2012 à 01:29, Stefano Lattarini a écrit :
* lib/am/header-vars.am (SUBDIRS): ... in the definition of this (instead
of using hand-rolled almost-equivalent) ...
($(1)LOG_DRIVER, TEST_EXTENSIONS): ... and of these (instead of resorting
to weaker and unsafer '?=' assignment).
Ack.
Le 30 juil. 2012 à 15:28, Stefano Lattarini a écrit :
This is a pure refactoring with no semantic changes intended. It will
only be useful for future changes.
* automake.in (handle_configure): Move definition of $(AM_CONF_HEADERS)
from here ...
(handle_config_headers): ... to this new
Le 30 juil. 2012 à 17:06, Stefano Lattarini a écrit :
* automake.in (generate_makefile): Move the hack necessary to make the
installation of libtool libraries and binaries dependent on them work
on degenerate systems even with make -j (according to the comments of
the original authors :-)
Le 30 juil. 2012 à 17:56, Stefano Lattarini a écrit :
* lib/am/common-targets.am: New file, superseding and encompassing ...
* lib/am/check-target.am, all-target.am, lib/am/install.am: ... these
ones.
* Makefile.am (dist_am_DATA): Adjust.
* automake.in (handle_all_and_check): Remove.
Le 27 juil. 2012 à 10:39, Stefano Lattarini a écrit :
* lib/am/header-vars.am (DESTDIR): It's not because we want to allow
I guess s/not//.
it to be defined from the environment, for compatibility with mainline
Automake. For better clarity, define an (empty) default with the line
DESTDIR
Le 24 juil. 2012 à 10:12, Stefano Lattarini a écrit :
This is a follow-up to today's commit v1.12.2-594-geee3aff.
* t/subpkg.sh: Here: do bee too picky about the verb declension
do bee?
don't be I guess, but there might be a reference to Harry
Potter that I don't grasp :)
used in a
Le 24 juil. 2012 à 10:13, Stefano Lattarini a écrit :
This issue is very similar to the one fixed by commit v1.12.2-31-g587e0c6.
The test 't/memoize.sh' was producing a '.log' file with few overly-long
lines (more than 12k characters long) and, when Solaris XPG4 awk was in
use, that was
Le 21 juil. 2012 à 10:50, Stefano Lattarini a écrit :
See long-standing automake bug#7868.
* t/parallel-tests-many.sh: Simplify and enhance. Among the other things,
I would s/the //.
this test now tries running ~ 30 thousands tests. Currently fails on
I would also 30,000, I don't like
Le 21 juil. 2012 à 10:50, Stefano Lattarini a écrit :
Fixes automake bug#7868.
Two things worth noting:
+ a make recheck issued after a huge number of tests have failed
can still hit command-line length issues;
+ the check-recipes now contain (first among the Automake-generated
Le 22 juil. 2012 à 09:58, Stefano Lattarini a écrit :
I personally use it extensively in my test suites, as I find this
much more legible:
! list_logs | grep .
Ah, but this doesn't do what you expect:
$ bash -c '! echo x | grep .'; echo st = $?
x
st = 0
$ bash -c '! echo | grep
Le 21 juil. 2012 à 10:50, Stefano Lattarini a écrit :
* lib/am/parallel-tests.am ($(TEST_SUITE_LOG)): Here, with the help
of ...
(am__count_test_results): ... this new internal variable.
Ack.
Le 21 juil. 2012 à 10:50, Stefano Lattarini a écrit :
* lib/am/parallel-tests.am (am__count_test_results): Adjust this awk
program to emit a shell snippet to be executed by the calling recipe ...
($(TEST_SUITE_LOG)): ... here. This avoid the need to call the program
in
Le 21 juil. 2012 à 10:50, Stefano Lattarini a écrit :
* t/parallel-tests-many.sh: Extend to check that the 'recheck' target
works even when a huge number of tests (~ 30 thousands) have failed
30k?
in the previous testsuite run. Currently this doesn't work, and cause
causes
the test to
Le 21 juil. 2012 à 10:50, Stefano Lattarini a écrit :
+## Re-run the relevant tests, without hitting command-line length limits.
+ echo am__test_bases=$$bases | \
+ $(MAKE) -f- -f$(firstword $(MAKEFILE_LIST)) \
+ $(TEST_SUITE_LOG) .am/doing-recheck=yes
Nice and
Le 21 juil. 2012 à 16:14, Stefano Lattarini a écrit :
Will push these shortly.
Stefano Lattarini (2):
automake: new function almost_verbatim (small refactoring)
automake: inline 'handle_install'
Sure.
Le 14 juil. 2012 à 23:49, Stefano Lattarini a écrit :
That is, it's hard-coded into the POSIX shell grammar that a
simple_command can start with redirections in the cmd_prefix, but a
compound_command can ONLY have redirections after the end of the
compound command, if you are being portable
Le 13 juil. 2012 à 12:19, Stefano Lattarini a écrit :
* t/dist-many.sh: New test, try distributing ~ 30 thousands files.
Currently fails on several systems (e.g., Linux 2.6.30 on i686,
Solaris 10 on i86pc).
* t/dist-many2.sh: New test, check that our distribution rules do not
hit errors due
Le 13 juil. 2012 à 12:19, Stefano Lattarini a écrit :
* lib/am/distdir.am: Here, so that we will be able to use them several
times with no performance impact.
Fine.
Le 13 juil. 2012 à 12:19, Stefano Lattarini a écrit :
+ @while read file; do \
## Always look for the file or directory to distribute in the build
## directory first, in VPATH spirit.
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
@@ -191,7 +200,7 @@
Le 13 juil. 2012 à 19:31, Stefano Lattarini a écrit :
On 07/13/2012 04:20 PM, Akim Demaille wrote:
Sorry about these. Updated below, and in the branch too.
Thanks. I'm still seeing the test case 'yacc-bison-skeleton.sh' failing
on the Debian 64 bit system gcc10.fsffrance.org. Below
Le 14 juil. 2012 à 09:13, Akim Demaille a écrit :
The failure is due to the input:
%{
int yylex () { return 0; }
void yyerror (const char *s) { return; }
%}
%%
foobar : 'f' 'o' 'o' 'b' 'a' 'r' {};
%{%} goes into the header when there is one, and it also goes
in the implementation
Well, while at it, I looked at the other failure, for C++, and
fixed them.
It is installed in yacc-work.
Akim Demaille (4):
tests: upgrade and fix Bison test case
ylwrap: refactoring: don't rely on the file order
ylwrap: refactor: move loop invariant
ylwrap: fix C++ support
lib/ylwrap
* t/yacc-bison-skeleton-cxx.sh: Request locations, to be
even more stressful.
Use %union to make sure the %{...%} is inserted where appropriate.
Fix some indentation/coding style issues.
---
t/yacc-bison-skeleton-cxx.sh | 20
1 file changed, 12 insertions(+), 8 deletions(-)
Forthcoming changes will make us iterate over the files in a different
order.
lib/ylwrap (first): Remove, replaced by...
(parser): this.
---
lib/ylwrap | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/lib/ylwrap b/lib/ylwrap
index 725b388..4ad820d 100755
---
* lib/ylwrap (input_rx): Move its definition next to its sibling's,
outside of the main loop.
---
lib/ylwrap | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/lib/ylwrap b/lib/ylwrap
index 4ad820d..3efa632 100755
--- a/lib/ylwrap
+++ b/lib/ylwrap
@@ -108,6 +108,7 @@ case
Le 14 juil. 2012 à 10:49, Stefano Lattarini a écrit :
Hi Akim.
ACK, with one question ...
cat foo.cc 'END'
#include zardoz.hh
-using namespace std;
-
Why this change?
Well, the question is rather: why this line? It's useless,
like a useless #include.
Le 14 juil. 2012 à 12:33, Stefano Lattarini a écrit :
I've also rebased 'yacc-work' on maint (rather than on master), and
pushed the follow-up below to avoid a spurious failure.
I will do some testing on BSD and Solaris, and if there are no further
issues, the merge the series in maint.
Le 14 juil. 2012 à 11:09, Stefano Lattarini a écrit :
On 07/14/2012 10:52 AM, Stefano Lattarini wrote:
On 07/14/2012 10:32 AM, Akim Demaille wrote:
Well, while at it, I looked at the other failure, for C++, and
fixed them.
It is installed in yacc-work.
Akim Demaille (4):
tests
Le 12 juil. 2012 à 17:51, Stefano Lattarini a écrit :
On 07/12/2012 03:51 PM, Akim Demaille wrote:
* lib/ylwrap (pairwise): Instead of being a straightforward copy from
the command line arguments, and having to deal with y.tab vs. y_tab
later, let pairwise store the real file names
Le 12 juil. 2012 à 18:22, Stefano Lattarini a écrit :
On 07/12/2012 03:51 PM, Akim Demaille wrote:
* lib/am/yacc.am (am__yacc_c2h): Shorten.
See below.
@@ -37,8 +37,7 @@ if %?MAINTAINER-MODE%
@MAINTAINER_MODE_FALSE@am__skipyacc = test -f $@ ||
endif %?MAINTAINER-MODE%
## The 's/c$/h
Le 12 juil. 2012 à 17:38, Stefano Lattarini a écrit :
Hi Akim.
On 07/12/2012 03:51 PM, Akim Demaille wrote:
The following patches address a bug in ylwrap that cause it
to be unable to handle Bison glr parsers, but also prevents
future Bison releases from also using header inclusion
Le 13 juil. 2012 à 13:43, Stefano Lattarini a écrit :
See? Another thing I had got wrong, given my ignorance and the lack
of a proper explanation ;-)
I also meant that the bug is obvious :) If you rename files, you
have to rename files that use them, and that this is in the context
of Bison
, and in the branch too.
From ee7e1dd77b5bcd6a41a31030a4f662bca3ad2b39 Mon Sep 17 00:00:00 2001
From: Akim Demaille a...@lrde.epita.fr
Date: Fri, 13 Jul 2012 14:32:22 +0200
Subject: [PATCH] ylwrap: rename header inclusion in generated parsers
Some types of Bison parsers, such as the GLR ones, generate a header
* lib/ylwrap (pairwise): Instead of being a straightforward copy from
the command line arguments, and having to deal with y.tab vs. y_tab
later, let pairwise store the real file names to process, y_tab
conversion included when needed.
(main loop): Use $to instead of $2, for symmetry with $from.
/Makefile.in
# doc/Makefile.in
# lib/Automake/Makefile.in
# lib/Makefile.in
# lib/am/Makefile.in
# m4/Makefile.in
Akim Demaille (3):
ylwrap: refactor
ylwrap: simplify the list of renamings
ylwrap: rename header inclusion in generated parsers
lib/am/yacc.am| 3
* lib/ylwrap (guard): New function.
Move functions before actual code.
---
lib/ylwrap | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/lib/ylwrap b/lib/ylwrap
index 6879d8d..fd29af8 100755
--- a/lib/ylwrap
+++ b/lib/ylwrap
@@
Le 8 juil. 2012 à 01:05, Stefano Lattarini a écrit :
diff --git a/t/built-sources.sh b/t/built-sources.sh
index 902cee1..b61b556 100755
--- a/t/built-sources.sh
+++ b/t/built-sources.sh
@@ -29,12 +29,14 @@ BUILT_SOURCES = foo.c
+ # Use printf, not echo, to avoid spurious interpretation
Le 9 juil. 2012 à 12:12, Stefano Lattarini a écrit :
seen?
Yep, stupid typo. Feel free to correct it (I assume you still have
pushing right for the Automake repository, right?)
I don't see it pushed. Aren't you working in ng/master?
I see this.
commit
Le 7 juil. 2012 à 22:40, Stefano Lattarini a écrit :
This series is the first step of the planned removal of several of the
annoying issues due to command line length limit that plague some important
Automake rules, especially on systems where such limits are tighter (e.g.,
the BSD systems)
Hi Stefano,
Le 5 juil. 2012 à 17:24, Stefano Lattarini a écrit :
$ cat Makefile
all:
echo all
Makefile: foo bar baz
As I said in my previous mail, I've already tried something like this, but
sadly it kept broking the 'remake-gnulib-add-acsubst.sh' test case, which
exercises a
Le 4 juil. 2012 à 11:54, Stefano Lattarini a écrit :
Hi Akim.
Hi!
There no way to have PHONY targets first? About Makefile.
I'm not sure I'm following. You mean having a way to ensure some target are
considered before all the other ones (apart their dependencies, of course)?
Like, in
Ciao Stefano!
Le 2 juil. 2012 à 09:44, Stefano Lattarini a écrit :
Hi Akim,
On 07/02/2012 09:20 AM, Akim Demaille wrote:
Le 30 juin 2012 à 23:11, Stefano Lattarini a écrit :
Its tests are hopelessly failing now, it is complex to debug (and I'm
too ignorant about its aims and its
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.
Le 24 juin 2012 à 22:01, Stefano Lattarini a écrit :
Ah, but that will limit the scope of the '.am.clean-cmd.{f,d}' commands,
making them only able to act on the content of a give variable, rather
than on a generic list of items (which might or might not be variable
references). The
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 anybody is
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
(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
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 anybody is
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
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
Le 21 juin 2012 à 12:32, Stefano Lattarini a écrit :
OK.
+my @mostly_rms = map { \t-rm -f $_ } sort keys %compile_clean_files;
my ($coms, $vars, $rules) =
file_contents_internal (1, $libdir/am/compile.am,
new Automake::Location,
-
Le 21 juin 2012 à 12:32, Stefano Lattarini a écrit :
This change it introduces eight new internal variables, which our
all
can been appended to by our Makefile fragments to declare stuff that
should be cleaned upon the various make *clean targets; these new
variables are:
-
Le 21 juin 2012 à 12:32, Stefano Lattarini a écrit :
It's so small and dumb that it's easier and cleaner to just inline
it in the automake script.
* lib/am/depend.am: Delete.
* Makefile.am (dist_am_DATA): Remove it.
* automake.in (handle_languages): Just add the list of all the '.deps'
Le 21 juin 2012 à 12:32, Stefano Lattarini a écrit :
No need to keep them separated anymore.
* automake.in (%compile_clean_files): Delete.
(initialize_per_input): Don't reset it.
(handle_compile): Don't merge '%compile_clean_files'
contents into '%clean_files'.
(handle_single_transform):
Le 21 juin 2012 à 12:32, Stefano Lattarini a écrit :
+ foreach my $dir (%libtool_clean_directories)
+{
+ # '.libs' is for Unix, '_libs' for DOS.
+ $clean_dirs{$dir/.libs} = CLEAN;
+ $clean_dirs{$dir/_libs} = CLEAN;
[._]libs?
+}
+
+ if ($relative_dir eq '.')
+
1 - 100 of 799 matches
Mail list logo
