bug#20699: Acknowledgement (subdir-objects with source from sibling directory breaks distcheck)

On 2015-06-21 23:14, Hans-Bernhard Bröker wrote: > It's actually even a little worse: > > Any dependency on sources in another directory causes a simple "make clean" > in one directory to erase _all_ object files on that other one, i.e. if > docs/Makefile.am has > > noinst_PROGRAMS = a > > a_S

bug#20082: new warning from ar on rawhide systems

On 2015-04-17 17:54, Pavel Raiskup wrote: > [+cc Ralf] > > On Friday 27 of March 2015 21:43:14 Pavel Raiskup wrote: >> On Friday 27 of March 2015 10:51:36 Eric Blake wrote: >>> Hmm. How hard is it to change ARFLAGS to 'cr' instead of the default of >>> 'cru', so that projects that want to silence

bug#17908: [PATCH] dist: ordering of files in DIST_COMMON is deterministic now

> diff --git a/NEWS b/NEWS > index bdc9bb9..5d14c5e 100644 > --- a/NEWS > +++ b/NEWS > @@ -116,6 +116,10 @@ New in 1.14.2: > risks causing "Arg list too long" for projects using automatic > dependency tracking and having a ton of source files (bug#18744). > > + - Automake tries to offe

bug#14517: t/tags-pr12372.sh assumes that etags generates tags for all files

On 2013-06-03 15:21, Stefano Lattarini wrote: > On 06/03/2013 11:47 AM, Stefano Lattarini wrote: >> >> Peter Rosin wrote: >>> >>> Yup, I'm happy to test anything you come up with (within reason :-). >>> >> Here it is. Does it work for you?

bug#14493: [FYI] {micro} tests: slightly stricter checks in t/cxx-demo.sh

On 2013-06-03 12:02, Stefano Lattarini wrote: > This is a follow-up to the commit fixing automake bug#14493. > > * t/cxx-demo.sh: Also check that the built program returns the > correct (i.e., zero) exit status when run. And improve comments > a little while at it. Good catch! Cheers, Peter

bug#14517: t/tags-pr12372.sh assumes that etags generates tags for all files

On 2013-05-31 11:58, Stefano Lattarini wrote: > On 05/31/2013 11:52 AM, Peter Rosin wrote: >> I'm not going to write the patch this week though, and possibly >> not in the near future as I have other things ($$$) to do as well... >> > Not to worry, the bug remains open

bug#14517: t/tags-pr12372.sh assumes that etags generates tags for all files

On 2013-05-31 11:36, Stefano Lattarini wrote: >> With that info (and with the help of the docs for the --langmap option), I >> can make the test PASS *for this etags* with the below patch. >> >> I also question if it's wise to 'cat TAGS' in the test, as I have >> non-printable characters the tags f

bug#14517: t/tags-pr12372.sh assumes that etags generates tags for all files

Hi! I recently installed etags on Cygwin. $ etags --version Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert Compiled: Dec 11 2009, 11:42:40 Addresses: , http://ctags.sourceforge.net Optional compiled features: +wildcards, +regex, +internal-sort This caused t/tags-pr12372.sh (v1

bug#14501: dependency generation FAIL in t/subobj11a.sh

On 2013-05-30 10:44, Stefano Lattarini wrote: > Or even "depcmp: avoid trailing backslash in depfile for depmode=msvc7", > maybe? Pushed with your subject. Thanks! Cheers, Peter

bug#14501: dependency generation FAIL in t/subobj11a.sh

On 2013-05-29 11:23, Stefano Lattarini wrote: > On 05/29/2013 09:48 AM, Peter Rosin wrote: >> On 2013-05-29 09:41, Peter Rosin wrote: >>> Hi! >>> >>> On Automake master (baf8a1c22acce0908), t/subobj11a.sh fails >>> on MSYS/MSVC (depmode=msvc7msys),

bug#14500: t/subpkg.sh fails when $CC is not cc

On 2013-05-29 11:32, Stefano Lattarini wrote: > On 05/29/2013 09:24 AM, Peter Rosin wrote: >> Hi! >> >> I'm configuring Automake master (baf8a1c22acce0908) with: >> >> ./configure CC=".../compile cl ..." ... >> >> This appears to

bug#14499: broken texi2dvi causes a FAIL in t/txinfo-no-split.sh

On 2013-05-29 11:50, Stefano Lattarini wrote: > On 05/29/2013 08:33 AM, Peter Rosin wrote: >> Hi! >> >> On MSYS, I have this situation: >> >> $ texi2dvi --version >> You don't have a working TeX binary installed, but the texi2dvi script >> can&#x

bug#14494: ./test-driver missing in t/distcheck-pr10470.sh

On 2013-05-29 17:35, Stefano Lattarini wrote: > On 05/29/2013 05:20 PM, Peter Rosin wrote: >> On 2013-05-29 16:54, Stefano Lattarini wrote: >>> What if you do something like: >>> >>> $EGREP "(^| )(rm|find):.*$distdir" output >>> >>>

bug#14494: ./test-driver missing in t/distcheck-pr10470.sh

Sep 17 00:00:00 2001 From: Peter Rosin Date: Wed, 29 May 2013 17:10:40 +0200 Subject: [PATCH] tests: prune some weed in a non-POSIX test Fixes automake bug#14494. * t/distcheck-pr10470.sh: Make sure the test-driver is installed. Adjust to run_make changes. Adjust grep pattern to match new output

bug#14493: MSYS line ending problem in t/cxx-demo.sh

nditional to MinGW, I'll do > that myself. I'm pushing the below patch. Cheers, Peter >From 625678d54b616bf5c2db6c803f4b0746f70e3e53 Mon Sep 17 00:00:00 2001 From: Peter Rosin Date: Wed, 29 May 2013 16:53:55 +0200 Subject: [PATCH] tests: avoid a spurious failure on MSYS Fi

bug#14494: ./test-driver missing in t/distcheck-pr10470.sh

On 2013-05-29 16:23, Stefano Lattarini wrote: > On 05/29/2013 03:33 PM, Peter Rosin wrote: >> On 2013-05-29 10:50, Stefano Lattarini wrote: >>> On 05/29/2013 01:46 AM, Peter Rosin wrote: >>>> Hi! >>>> >>> Hi Peter, thanks for the report (and the

bug#14493: MSYS line ending problem in t/cxx-demo.sh

On 2013-05-29 10:57, Stefano Lattarini wrote: > On 05/29/2013 01:43 AM, Peter Rosin wrote: >> Hi! >> >> I have this interesting log snippet from a failed run of t/cxx-demo.sh >> on the master branch (commit baf8a1c22acce0908): >> > And as you noted in your f

bug#14494: ./test-driver missing in t/distcheck-pr10470.sh

On 2013-05-29 10:50, Stefano Lattarini wrote: > On 05/29/2013 01:46 AM, Peter Rosin wrote: >> Hi! >> > Hi Peter, thanks for the report (and the plethora of the following > ones :-) > >> On MSYS, t/distcheck-pr10470.sh from the master branch fails with this >

bug#14498: Failure with MSVC in t/yacc-bison-skeleton.sh

On 2013-05-29 11:56, Stefano Lattarini wrote: > On 05/29/2013 11:54 AM, Peter Rosin wrote: >> diff --git a/t/yacc-bison-skeleton.sh b/t/yacc-bison-skeleton.sh >> index b89d44c..3dfc83f 100644 >> --- a/t/yacc-bison-skeleton.sh >> +++ b/t/yacc-bison-skeleton.sh >&g

bug#14495: unistd.h problem in t/lex-header.sh

On 2013-05-29 11:51, Stefano Lattarini wrote: > On 05/29/2013 11:43 AM, Peter Rosin wrote: >> diff --git a/t/lex-header.sh b/t/lex-header.sh >> index 005ae86..0789af4 100644 >> --- a/t/lex-header.sh >> +++ b/t/lex-header.sh >> @@ -55,6 +55,7 @@ cat > lexer.l

bug#14498: Failure with MSVC in t/yacc-bison-skeleton.sh

On 2013-05-29 07:48, Peter Rosin wrote: > Hi! > > With the master branch (baf8a1c22acce0908) bison generates code with > a bunch of inline functions, but inline is spelled __inline with > MSVC, and the test fails spectacularly. > > An example error message: > zar

bug#14495: unistd.h problem in t/lex-header.sh

On 2013-05-29 11:06, Stefano Lattarini wrote: > On 05/29/2013 10:39 AM, Peter Rosin wrote: >> On 2013-05-29 02:08, Peter Rosin wrote: >>> Hi! >>> >>> When t/lex-header.sh tries to compile main.c on the master branch, it fails >>> like this snippe

bug#14498: Failure with MSVC in t/yacc-bison-skeleton.sh

On 2013-05-29 07:48, Peter Rosin wrote: > Hi! > > With the master branch (baf8a1c22acce0908) bison generates code with > a bunch of inline functions, but inline is spelled __inline with > MSVC, and the test fails spectacularly. The problem is the same on the micro branch (

bug#14495: unistd.h problem in t/lex-header.sh

On 2013-05-29 02:08, Peter Rosin wrote: > Hi! > > When t/lex-header.sh tries to compile main.c on the master branch, it fails > like this snippet below, since MSVC does not have unistd.h. I suppose main.c > should add > > #define YY_NO_UNISTD_H 1 > > before it i

bug#14494: ./test-driver missing in t/distcheck-pr10470.sh

On 2013-05-29 01:46, Peter Rosin wrote: > Hi! > > On MSYS, t/distcheck-pr10470.sh from the master branch fails with this > log file: The problem is the same on the micro branch (87e49f4f040c8ab). Cheers, Peter

bug#14493: MSYS line ending problem in t/cxx-demo.sh

On 2013-05-29 01:43, Peter Rosin wrote: > This is on MSYS, and I strongly suspect a line ending discrepancy. > The output from ./play is likely to have CRNL line endings, while > exp.play is likely to have NL line endings. diff then barfs. The problem is the same on the mic

bug#14501: dependency generation FAIL in t/subobj11a.sh

On 2013-05-29 09:41, Peter Rosin wrote: > Hi! > > On Automake master (baf8a1c22acce0908), t/subobj11a.sh fails > on MSYS/MSVC (depmode=msvc7msys), like this: > > + make quux > src/.deps/foo.Po:1: *** target pattern contains no `%'. Stop. > > > It appears

bug#14501: dependency generation FAIL in t/subobj11a.sh

Hi! On Automake master (baf8a1c22acce0908), t/subobj11a.sh fails on MSYS/MSVC (depmode=msvc7msys), like this: + make quux src/.deps/foo.Po:1: *** target pattern contains no `%'. Stop. It appears that the generated foo.Po is broken. Adding a cat "$depdir"/foo.Po just before the $MAKE qu

bug#14500: t/subpkg.sh fails when $CC is not cc

Hi! I'm configuring Automake master (baf8a1c22acce0908) with: ./configure CC=".../compile cl ..." ... This appears to cause the below FAIL in t/subpkg.sh. Cheers, Peter *snip* checking whether /home/peda/automake/lib/compile cl -nologo understands -c and -o together... yes *snip* === configur

bug#14499: broken texi2dvi causes a FAIL in t/txinfo-no-split.sh

Hi! On MSYS, I have this situation: $ texi2dvi --version You don't have a working TeX binary installed, but the texi2dvi script can't proceed without it. If you want to use this script, you have to install some kind of TeX, for example the MikTeX package from http://miktex.org/ (which is not part

bug#14498: Failure with MSVC in t/yacc-bison-skeleton.sh

Hi! With the master branch (baf8a1c22acce0908) bison generates code with a bunch of inline functions, but inline is spelled __inline with MSVC, and the test fails spectacularly. An example error message: zardoz.c(873) : error C2054: expected '(' to follow 'inline' $ bison --version bison (GNU Bi

bug#14495: unistd.h problem in t/lex-header.sh

Hi! When t/lex-header.sh tries to compile main.c on the master branch, it fails like this snippet below, since MSVC does not have unistd.h. I suppose main.c should add #define YY_NO_UNISTD_H 1 before it includes mylex.h? Or is this something else? I know very little about lexers... Chee

bug#14494: ./test-driver missing in t/distcheck-pr10470.sh

Hi! On MSYS, t/distcheck-pr10470.sh from the master branch fails with this log file: Running from installcheck: no Test Protocol: none PATH = /home/peda/automake/t/wrap:/home/peda/automake/t/ax:[elided] ++ pwd /home/peda/automake/t/distcheck-pr10470.dir + mkdir foo.d + sh -c 'cd foo.d && sleep '

bug#14493: MSYS line ending problem in t/cxx-demo.sh

Hi! I have this interesting log snippet from a failed run of t/cxx-demo.sh on the master branch (commit baf8a1c22acce0908): + for p in play work + ./play + cat exp.play We are playing :-) Howdy, play! + cat got.play We are playing :-) Howdy, play! + diff exp.play got.play 1,2c1,2 < We are playin

bug#13588: Pax hangs in case big UID

On 2013-04-25 14:19, Stefano Lattarini wrote: *snip* > * THANKS: Likewise. > * t/tar-ustar-id-too-high.sh: New test. > * t/list-of-tests.mk: Add it. > * t/tar2.sh: While at it, tweak and enhance a little. > * t/tar3.sh: Likewise. > * t/tar-override.sh: Likewise. > > Helped-by: Pavel Raiskup > Hel

bug#13578: [IMPORTANT] Savannah issues

On 2013-02-28 00:39, Stefano Lattarini wrote: > On 02/28/2013 12:00 AM, Peter Rosin wrote: >> >> [SNIP] >> >> What I meant was that you can use (some of) my above proposed merges >> to go forward with the new role for master instead of requiring help >>

bug#13524: Improving user experience for non-recursive builds

On 2013-02-08 09:45, Peter Rosin wrote: > Stefano Lattarini wrote: >> Fine as well. And of curse, if you want to speed thing up and have more >> control on the final result, feel free to shepherd the pending patches to >> the agreed form ;-) -- which if I'm not mista

bug#13524: [PATCH 2/2] preproc: enhance and extend tests

From: Stefano Lattarini * t/preproc-demo.sh: New test, a "demo" of how the new pre-processing feature could be used in a real-world package. * t/preproc-errmsg.sh: New test, check that error messages remain useful when the new pre-processing features are involved. * t/preproc-reldir.sh: Split up

bug#13524: [PATCH 1/2] preproc: add support for relative names in included fragments

d-off-by: Peter Rosin --- NEWS| 12 + automake.in | 26 -- doc/automake.texi | 20 t/list-of-tests.mk |1 + t/preproc-reldir.sh | 129 +++ 5 files changed, 182 insertions(+), 6 deletions(-)

bug#13524: Improving user experience for non-recursive builds

Stefano Lattarini wrote: > Fine as well. And of curse, if you want to speed thing up and have more > control on the final result, feel free to shepherd the pending patches to > the agreed form ;-) -- which if I'm not mistaken is: > > - make the series consist of only two patches, one introducing

bug#13588: Pax hangs in case big UID

Hi Petr! On 2013-02-05 13:00, Petr Hracek wrote: > just a one question regarding that problem > Can that patch applicable? As far as I can tell, the patch has other problems, but since those would be more obvious to whomever was going to shepherd this patch in (and I'm not what person) I didn't p

bug#13524: Improving user experience for non-recursive builds

On 2013-02-04 19:11, Stefano Lattarini wrote: > On 02/04/2013 06:33 PM, Eric Blake wrote: >> So they aren't quite affected by configure, but they are dependent on >> relative location, just like existing substitutions like @top_srcdir@ >> are dependent on relative location. >> > Yes, but they are d

bug#13524: Improving user experience for non-recursive builds

On 2013-02-04 14:43, Stefano Lattarini wrote: > On 02/04/2013 01:04 PM, Peter Rosin wrote: >> I {{think}} this one will be the easiest on us of all. BTW, that was a mix of "on us all" and "on all of us", if anyone didn't notice... >> > I tend to agree

bug#13524: Improving user experience for non-recursive builds

On 2013-02-04 12:33, Stefano Lattarini wrote: > On 02/04/2013 10:35 AM, Peter Rosin wrote: >> Not sure what to do about it, or if it matters... >> > It does IMHO, since the failure you pointed out, albeit easy to > work around, wouldn't be very obvious to diagnose, fro

bug#13524: Improving user experience for non-recursive builds

On 2013-02-04 12:23, Stefano Lattarini wrote: > On 02/04/2013 12:10 AM, Peter Rosin wrote: >> On 2013-02-03 21:42, Stefano Lattarini wrote: >>> I've pushed the promised patches to the rewindable branch >>> 'experimental/preproc' (based off of maint). I

bug#13524: Improving user experience for non-recursive builds

On 2013-02-04 00:10, Peter Rosin wrote: > On 2013-02-03 21:42, Stefano Lattarini wrote: >> I've pushed the promised patches to the rewindable branch >> 'experimental/preproc' (based off of maint). I'll also soon >> send them to the list to simplify revie

bug#13524: Improving user experience for non-recursive builds

On 2013-02-03 21:42, Stefano Lattarini wrote: > I've pushed the promised patches to the rewindable branch > 'experimental/preproc' (based off of maint). I'll also soon > send them to the list to simplify review (I will drop the > bug tracker from CC:, to avoid cluttering up the report). > > As us

bug#13588: Pax hangs in case big UID

Hi Petr, I have looked at this only cursory, but FWIW, On 2013-01-30 14:31, Petr Hracek wrote: *snip* > +AC_SUBST([AM_BIG_ID], [2097152]) *snip* > +#Test if $user_id is greater then 2^21 s/then/than/ And please add a space after the comment hash-marks. > +#if yes then failed

bug#13524: Improving user experience for non-recursive builds

Hi Stefano, On 2013-01-27 20:21, Stefano Lattarini wrote: >> This time with documentation and a NEWS entry. I also fixed the case >> of including something above the current base Makefile.am with a >> relative path, e.g.: >> >> include ../top.mk >> >> That change shaved a couple of more lines

bug#13524: Improving user experience for non-recursive builds

On 2013-01-25 17:03, Peter Rosin wrote: > On 2013-01-24 13:22, Peter Rosin wrote: >> On 2013-01-23 16:08, Stefano Lattarini wrote: >>> On 01/23/2013 03:34 PM, Peter Rosin wrote: >>>> On 2013-01-23 13:45, Stefano Lattarini wrote: >> *snip* >>>>>

bug#13524: Improving user experience for non-recursive builds

On 2013-01-24 13:22, Peter Rosin wrote: > On 2013-01-23 16:08, Stefano Lattarini wrote: >> On 01/23/2013 03:34 PM, Peter Rosin wrote: >>> On 2013-01-23 13:45, Stefano Lattarini wrote: > *snip* >>>> Too much automagic here IMO. We'd better have two distinct su

bug#13524: Improving user experience for non-recursive builds

On 2013-01-23 16:08, Stefano Lattarini wrote: > On 01/23/2013 03:34 PM, Peter Rosin wrote: >> On 2013-01-23 13:45, Stefano Lattarini wrote: *snip* >>> Too much automagic here IMO. We'd better have two distinct subst, one for >>> the "real" dire

bug#13524: Improving user experience for non-recursive builds

e useful > as a reference to me or other developers in the future. Well, apparently I was in the mood and found some more time :-) > On 01/22/2013 11:22 AM, Peter Rosin wrote: >> From 5cc9c775dbe46343b651a7e6ac378f71e6a3b6c1 Mon Sep 17 00:00:00 2001 >> From: Peter Rosin >>

bug#13524: Improving user experience for non-recursive builds

ntents (this too was Bob's suggestion, > IIRC); in which case, the change would probably be unobtrusive and mostly > safe. Patches (even WIP) are welcome. This is proof of concept, and I'm not a perl hacker etc, but it seems to work ok. Feel free to improve or toss or add docume

bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the default, and only available one

On 2013-01-08 22:42, Stefano Lattarini wrote: > On 01/08/2013 10:06 PM, Peter Rosin wrote: >> On 2013-01-08 16:15, Stefano Lattarini wrote: >>> That would be overkill, since AM_PROG_CC_C_O is only required by >>> projects doing C compilation. >> >> Hi, >&

bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the default, and only available one

On 2013-01-08 20:27, Stefano Lattarini wrote: > On 01/08/2013 04:29 PM, Eric Blake wrote: >> On 01/08/2013 08:15 AM, Stefano Lattarini wrote: >>> In addition, AM_PROG_CC_C_O is not required by >>> projects that don't care about catering to inferior compilers. >> >> How much speed penalty and confi

bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the default, and only available one

On 2013-01-08 16:15, Stefano Lattarini wrote: > That would be overkill, since AM_PROG_CC_C_O is only required by > projects doing C compilation. Hi, However, a notorious C++ compiler from Redmond is inferior also in its C++ mode and would benefit from an AM_PROG_CXX_C_O variant. If the meat of AM

bug#12210: Acknowledgement (Timestamp race in python-missing test)

On 2012-08-16 18:55, Stefano Lattarini wrote: > On 08/16/2012 05:14 PM, Adam Sampson wrote: >> The python-am-path-iftrue test has the same problem (and the same fix). >> > Confirmed and fixed with the attached patch (which uses the '--force' > autoconf option rather than 'sleep', to avoid slowing d

bug#12198: [PATCH] tests: fixup: make distcheck-override-infodir pass again

On 2012-08-14 18:53, Stefano Lattarini wrote: > On 08/14/2012 06:44 PM, Stefano Lattarini wrote: >> Hi Peter, thanks for the report and the fix. >> >> On 08/14/2012 03:25 PM, Peter Rosin wrote: >>> >>> Ok to push this fix to maint? >>> >>&g

bug#12198: automake 1.12.3 self-tests failure: t/distcheck-override-infodir

On 2012-08-14 15:14, Simon Josefsson wrote: > Hi. It builds and passes self-checks except for the > t/distcheck-override-infodir test. Output below. > > /Simon > > FAIL: t/distcheck-override-infodir A post is (soon) available in automake-patches, I posted it 10 minutes before seeing your repor

bug#10766: bug#11893: Regression in automake 1.12.1 on Mac OS X

On 2012-07-12 16:37, Stefano Lattarini wrote: > On 07/12/2012 04:00 PM, Peter Rosin wrote: >> >> Stefano Lattarini wrote: >>> >>> Since that requirement is only needed for bootstrapping, I could send >>> you a (patched) tarball to test (so that you'l

bug#11893: Regression in automake 1.12.1 on Mac OS X

On 2012-07-12 17:48, Eric Blake wrote: > On 07/12/2012 08:37 AM, Stefano Lattarini wrote: > Agreed (albeit it does its dirty work for now). Any suggestion on how to make it more reliable? >>> >>> Is test /usr/bin/CC -ef /usr/bin/cc portable enough? >>> >> I have no idea ... it seems to

bug#10766: bug#11893: Regression in automake 1.12.1 on Mac OS X

On 2012-07-12 10:51, Stefano Lattarini wrote: > Hi Peter. > > On 07/11/2012 11:21 PM, Peter Rosin wrote: >> On 2012-07-11 14:44, Stefano Lattarini wrote: >>> On 07/09/2012 07:04 PM, Max Horn wrote: >>> >>>> I am currently looking into

bug#10766: bug#11893: Regression in automake 1.12.1 on Mac OS X

h incorrectly (!) succeeds. >> >> There are two problems here: >> >> 1) The C++ compiler from Sun Studio is named "CC". This caused >> t/silentcxx.sh to fail, which was fixed with commit ad5d0be02d >> in the autonconf >> > s/autoconf/automake/

bug#11401: automake-1.12 (incorrectly?) complains about missing AM_PROG_AR

Hi Mike! On 2012-05-04 07:25, Mike Frysinger wrote: > consider this simple code base: > $ cat configure.ac > AC_PREREQ([2.63]) > AC_INIT([foo], [0]) > AM_INIT_AUTOMAKE([1.11 -Wall foreign]) > AC_PROG_CC > LT_INIT > AC_OUTPUT(Makefile) > > $ cat Makefile.am > lib_LTLIBRARIES = libfoo.la > libfoo_l

bug#11356: automake 1.12 and (C) 2011

On 2012-04-27 16:34, Stefano Lattarini wrote: > -# Copyright (C) 1996-2012 Free Software Foundation, Inc. > +# Copyright (C) 1996-$RELEASE_YEAR Free Software Foundation, Inc. Isn't a paradigm like that "risky" for the case of a late maintenance release a couple of years after the last release on s

bug#11185: flex %option "never-interactive" breaks few tests on Solaris

On 2012-04-05 15:40, Stefano Lattarini wrote: > Severity: minor > thanks > > Hello automakers, Peter. > > The commit v1.11-2058-g6f4b08d of 06-03-2012, "tests: explicitly state > that our lexers do not require unistd.h", has been causing at least > the tests 'lex-clean-cxx.test' and 'lex-depend-c

bug#11153: change automake branching policy: dispensing with the 'branch-X.Y' branches in the future

On 2012-04-04 11:50, Stefano Lattarini wrote: > On 04/03/2012 12:01 AM, Peter Rosin wrote: >> >> [SNIP] >> >> I'll try to explain what I mean again... >> >> I think we should do exactly as you describe above. However, for the >> class of changes

bug#11153: change automake branching policy: dispensing with the 'branch-X.Y' branches in the future

On 2012-04-02 21:42, Stefano Lattarini wrote: > Hi Peter, thanks for the feedback. But I fear we have a misunderstanding > here. See below. > > On 04/02/2012 08:14 PM, Peter Rosin wrote: >> On 2012-04-02 18:13, Stefano Lattarini wrote: >>> Severity: wishlist >>

bug#11153: change automake branching policy: dispensing with the 'branch-X.Y' branches in the future

On 2012-04-02 18:13, Stefano Lattarini wrote: > Severity: wishlist > thanks > > Hello Automakers. > > After some real hand-on experience with the current branching policy > of Automake, I'm convinced the presence of the 'branch-X.Y' branches > is just an annoyance and a source of confusion, and t

bug#8880: [PATCH] add pgcc support to depcomp

Dave Goodell skrev 2012-02-25 03:22: > Portland Group C Compiler support based on a code from Jeff Daily @ PNNL > via the automake list and automake bug #8880: > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8880 > --- > lib/depcomp | 74 > +

bug#10766: CXX gets the value 'CC' on Cygwin, but CC is in fact cc

Stefano Lattarini skrev 2012-02-08 22:31: > Reference: > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10766> > > [CC:ing the bug-autoconf list] > > On 02/08/2012 10:04 PM, Peter Rosin wrote: >> Hi! >> >> The testsuite on master tries to use lesser co

bug#10766: CXX gets the value 'CC' on Cygwin, but CC is in fact cc

Hi! The testsuite on master tries to use lesser compilers, but on Cygwin this causes some failures due to the fact that /usr/bin/cc{.exe} is also recognized as /usr/bin/CC{.EXE} (due to the filesystem not being case sensitive), leading to CXX being set to 'CC'. But then CXX isn't a C++ compiler a

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake

Stefano Lattarini skrev 2012-02-08 00:01: > Hi Peter, thanks for the invaluable feedback. Thanks for the appreciation, but "invaluable" is perhaps a bit over the top... > On 02/07/2012 10:05 PM, Peter Rosin wrote: >> Stefano Lattarini skrev 2012-02-05 14:16: >>>

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake

Stefano Lattarini skrev 2012-02-05 14:16: > On 02/02/2012 11:41 PM, Peter Rosin wrote: >> Stefano Lattarini skrev 2012-02-02 22:45: >>> Reference: >>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10434> >>> >>> OK, the attached patch fixes the

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake

Stefano Lattarini skrev 2012-02-05 14:16: > On 02/02/2012 11:41 PM, Peter Rosin wrote: >> Stefano Lattarini skrev 2012-02-02 22:45: >>> Reference: >>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10434> >>> >>> OK, the attached patch fixes the

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake

Stefano Lattarini skrev 2012-02-02 22:45: > Reference: > > > OK, the attached patch fixes the two spurious failures of GCC forced into > Tru64 mode. About time I'd say. > > But I'm not sure whether we should apply this without first testing

bug#10671: Automake 1.11 Test Suite Bug Report

Stefano Lattarini skrev 2012-02-01 09:49: > On 01/31/2012 09:15 PM, Matthew Wezowicz wrote: >> The OS is CentOS 6.2 x86_64 >> Kernel Version: 2.6.32-220.4.1.el6.x86_64 >> GCC Version: 4.4.6 >> Autconf Version: 2.68 >> Libtool Version: 2.4 >> >> The stdinc.dir and stdinc.log are attached as a .tar.

bug#10466: MSYS problem with redirects

Stefano Lattarini skrev 2012-01-27 13:20: > tags 10466 + patch > severity 10466 minor > thanks > > On 01/16/2012 12:40 PM, Peter Rosin wrote: >> Sorry for the delay. >> > Ditto here :-) > >> Stefano Lattarini skrev 2012-01-09 20:32: >>> On

bug#10466: [PATCH] tests: improve diagnostics when write(2) fails

Stefano Lattarini skrev 2012-01-23 10:04: > On 01/23/2012 09:48 AM, Peter Rosin wrote: >> Stefano Lattarini skrev 2012-01-09 20:32: >> >>> BTW, this change might be independently useful in catching other potential >>> unexpected write failures; would you feel

bug#10466: [PATCH] tests: improve diagnostics when write(2) fails (was: bug#10466: MSYS problem with redirects)

Stefano Lattarini skrev 2012-01-09 20:32: > On 01/09/2012 12:29 PM, Peter Rosin wrote: >> With this diff: >> >> diff --git a/tests/parallel-tests-fd-redirect.test >> b/tests/parallel-tests-fd-red >> index 73a134e..5728014 100755 >> --- a/tests/paralle

bug#10555: automake: wrong use of F77FLAGS instead of FFLAGS?

Stefano Lattarini skrev 2012-01-21 10:26: > On 01/20/2012 09:08 PM, Peter Rosin wrote: >> Stefano Lattarini skrev 2012-01-20 20:53: >>> On 01/19/2012 02:45 PM, Stefano Lattarini wrote: >>>> >>>> [SNIP] >>>> >>>> So, to al

bug#10555: automake: wrong use of F77FLAGS instead of FFLAGS?

Stefano Lattarini skrev 2012-01-20 20:53: > On 01/19/2012 02:45 PM, Stefano Lattarini wrote: >> >> [SNIP] >> >> So, to all autoconfers: do you happen to know any reason for which Automake >> should use F77FLAGS? If not, I'll assume that is due to a typo or clerical >> mistake, and fix it (in 48 hou

bug#10466: MSYS problem with redirects

Sorry for the delay. Stefano Lattarini skrev 2012-01-09 20:32: > On 01/09/2012 12:29 PM, Peter Rosin wrote: >> Hi! >> >> parallel-tests-fd-redirect.test fails on MSYS, and I think >> the cause is that the write (9, ...) simply doesn't work for >> MinGW pr

bug#10470: MSYS: race in directory access?

Stefano Lattarini skrev 2012-01-13 10:05: > Good to know. I've amended the git commit message of the second patch > accordingly, to read as follows: > > dist: avoid $(distdir) removal failure on MSYS/MinGW > > This change fixes automake big#10470. s/big/bug/ (in case there is some autom

bug#10470: MSYS: race in directory access?

Stefano Lattarini skrev 2012-01-12 10:15: > On 01/11/2012 08:27 PM, Peter Rosin wrote: >> Stefano Lattarini skrev 2012-01-11 18:31: >>> Hi Peter, sorry for the delay. >> >> No rush! >> >>>>>>> We could enhance your original

bug#10470: MSYS: race in directory access?

Stefano Lattarini skrev 2012-01-11 18:31: > Hi Peter, sorry for the delay. No rush! > We could enhance your original workaround like this: > > am__remove_distdir = \ >{ test ! -d "$(distdir)" \ > || { find "$(distdir)" -type d ! -perm -200 -exec chmod u+w {} ';' \ >>

bug#10470: MSYS: race in directory access?

Stefano Lattarini skrev 2012-01-10 18:03: >>> It would probably be worthwhile to try to understand why this is the case. >>> As a wild guess, would this work? >>> >>> - ( sleep 1 ) & >>> + sh -c "cd '$abs_builddir'; sleep 1" & >> >> No, fails in the same way as the original. >> > Sorry, by bad,

bug#10470: MSYS: race in directory access?

Stefano Lattarini skrev 2012-01-10 16:02: > On 01/10/2012 02:13 PM, Peter Rosin wrote: >> Stefano Lattarini skrev 2012-01-10 13:44: >>> On 01/10/2012 12:35 PM, Peter Rosin wrote: >>>> >>>> One further data point; changing that "( sleep 1 ) &&q

bug#10470: MSYS: race in directory access?

Stefano Lattarini skrev 2012-01-10 13:44: > On 01/10/2012 12:35 PM, Peter Rosin wrote: >> Peter Rosin skrev 2012-01-10 11:12: >>> Stefano Lattarini skrev 2012-01-10 10:50: >>>> [2] Now that I think of it, my knee-jerk guess is that the "( sleep 1 ) &"

bug#10470: MSYS: race in directory access?

Peter Rosin skrev 2012-01-10 11:12: > Stefano Lattarini skrev 2012-01-10 10:50: >> [2] Now that I think of it, my knee-jerk guess is that the "( sleep 1 ) &" >> put in configure by AM_SANITY_CHECK is the likely culprit. > > I tried that hypothesis and bump

bug#10470: MSYS: race in directory access?

Stefano Lattarini skrev 2012-01-10 10:50: > Hi Peter. > > On 01/10/2012 12:15 AM, Peter Rosin wrote: >> Peter Rosin skrev 2012-01-10 00:07: >>> Hi! >>> >>> distcheck-configure-flags-am.test fails on MSYS. >> > Is this failure consistently reprodu

bug#10465: MSYS read-only file trouble

Stefano Lattarini skrev 2012-01-10 09:48: > Hi Eric, Peter, and thanks to both for the super-quick diagnosis and fix. > > On 01/10/2012 12:52 AM, Peter Rosin wrote: >> Eric Blake skrev 2012-01-10 00:34: *snip* >>> Ah - the classic bash bug documented in the autoconf manua

bug#10465: MSYS read-only file trouble

Eric Blake skrev 2012-01-10 00:34: > On 01/09/2012 03:42 PM, Peter Rosin wrote: >> FWIW, this "fixes" it, but I don't actually know why a subshell would >> make a difference? >> >> $ sh --version >> GNU bash, version 3.1.17(1)-release (i686-pc-ms

bug#10470: MSYS: race in directory access?

Peter Rosin skrev 2012-01-10 00:07: > Hi! > > distcheck-configure-flags-am.test fails on MSYS. I think the cause is > that some process lingers with CWD in the _build directory which some > other process tries to remove. On MSYS, it's not possible to remove a > director

bug#10470: MSYS: race in directory access?

Hi! distcheck-configure-flags-am.test fails on MSYS. I think the cause is that some process lingers with CWD in the _build directory which some other process tries to remove. On MSYS, it's not possible to remove a directory that is "in use" like that. Ugly patch coming up shortly. Cheers, Pete

bug#10465: MSYS read-only file trouble

Peter Rosin skrev 2012-01-09 23:14: > Stefano Lattarini skrev 2012-01-09 20:52: >> On 01/09/2012 08:11 PM, Peter Rosin wrote: >>> Stefano Lattarini skrev 2012-01-09 20:03: >>>>> + ./tap-driver --test-name zardoz --log-file zardoz.log --trs-file >>>&g

bug#10465: MSYS read-only file trouble

Stefano Lattarini skrev 2012-01-09 20:52: > On 01/09/2012 08:11 PM, Peter Rosin wrote: >> Stefano Lattarini skrev 2012-01-09 20:03: >>>> + ./tap-driver --test-name zardoz --log-file zardoz.log --trs-file >>>> zardoz.trs -- sh -c 'echo 1..1; echo o

bug#10465: MSYS read-only file trouble

Stefano Lattarini skrev 2012-01-09 20:03: >> + ./tap-driver --test-name zardoz --log-file zardoz.log --trs-file >> zardoz.trs -- sh -c 'echo 1..1; echo ok 1; echo "Hello, World!"' >> + st=1 >> > Hmmm... looks like the shell is not returning a non-zero exit status in > face of a I/O redirection fai

bug#10324: [Platform-testers] Automake 1.11.1b test release

Hi Bruno, Bruno Haible skrev 2012-01-08 20:45: > Hi Peter, > > You wrote in > : >> Oh crap, you are crossing over from Cygwin without telling the build >> system, right? Or what is your $build if you don't specify --host? >> I

  1   2   >