bug#9768: Makefile broken after removing included *.am file

* Stefano Lattarini wrote on Mon, Oct 17, 2011 at 10:20:05AM CEST: > On Sunday 16 October 2011, Ralf Wildenhues wrote: > > What happens if I write > > include fragment-with-typo-in-name.am > > > > but I want that fragment included? > > > I fear I cannot par

bug#9768: Makefile broken after removing included *.am file

Hello, * Stefano Lattarini wrote on Sun, Oct 16, 2011 at 08:27:12PM CEST: > On Sunday 15 November 2009, Peter Johansson wrote: > > make: *** No rule to make target `aminclude.am', needed by > > `Makefile.in'. Stop. > > > > This is very similar to the "deleted header file problem" for *.m4 files

bug#9080: config.guess of automake not up to date (AIX 7.1)

* Christian Volkmann wrote on Thu, Jul 14, 2011 at 01:28:23PM CEST: > config.guess of the automake package does not detect AIX 7.1. > It detects rs6000-ibm-aix instead of powerpc-ibm-aix7.1.0.0 > > Please update this file for the next automake release, I've ran make fetch in maint and merged in

bug#9088: Java support

Hello, allow me a couple of ranty comments: * Stefano Lattarini wrote on Fri, Jul 15, 2011 at 10:58:01AM CEST: > I'd rather deprecate the JAVA primary, and then introduce a new `JARS' > primary, to be used e.g. as follows: First off, we've _never_ removed support for a primary, and I don't think

bug#8969: improve synchronization between examples in the manual and test cases

* Stefano Lattarini wrote on Fri, Jul 01, 2011 at 12:59:53AM CEST: > Subject: [PATCH] docs, tests: synchronize examples from docs to tests > > * tests/README (Writing test cases): Give suggestions on how to > keep test cases and examples in the documentation synchronized. > * doc/automake.texi: Im

bug#8921: side stepping automake limitations with custom dependencies

Hi Mike, * Mike Frysinger wrote on Thu, Jun 23, 2011 at 02:07:30AM CEST: > ah blah, i meant autom...@gnu.org. i dont know how to close bugs with this e- > mail system, so if someone could do that for me, that'd be cool ... Write to BUG-done@... Done. ;-) Cheers, Ralf

bug#8718: error when using nested conditionals

* Bruno Haible wrote on Fri, Jun 17, 2011 at 12:21:38PM CEST: > Ralf Wildenhues wrote: > > > There's no point in being _that_ safe that you check unused expressions > > > for validity. C compilers don't do it either: When I compile a C program > &g

bug#8718: error when using nested conditionals

* Ralf Wildenhues wrote on Fri, Jun 17, 2011 at 07:47:35AM CEST: > * Bruno Haible wrote on Thu, Jun 16, 2011 at 11:42:51PM CEST: > > > > AM_CONDITIONAL([USE_VARIANT_A], [$use_variant_a]) > > > > > > Instead of this line, you could use > > >

bug#8718: error when using nested conditionals

* Bruno Haible wrote on Thu, Jun 16, 2011 at 11:42:51PM CEST: > > > AM_CONDITIONAL([USE_VARIANT_A], [$use_variant_a]) > > > > Instead of this line, you could use > > AC_CONFIG_COMMANDS_PRE([AM_CONDITIONAL([...])]) > > I cannot force the gnulib users to write autoconf macros which deviate that

bug#8718: error when using nested conditionals

Hello, and sorry for the delay, * Bruno Haible wrote on Fri, Jun 10, 2011 at 01:29:57AM CEST: > > Cannot you simply initialize the > > automake conditionals you might need and that you know might be called > > conditionally to (possibly dummy) defaults in gl_INIT or gl_EARLY or > > something like

bug#8784: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS

* Stefano Lattarini wrote on Fri, Jun 10, 2011 at 05:33:39PM CEST: > > On Thursday 02 June 2011, Stefano Lattarini wrote: > > Continuing with the good trend of avoiding to impinge on the user > > namespace, we should start supporting AM_DISTCHECK

bug#8635: Some Fortran files don't have the extensions automake wants

* Stefano Lattarini wrote on Mon, May 09, 2011 at 02:11:53PM CEST: > --- a/automake.in > +++ b/automake.in > @@ -939,7 +939,7 @@ register_language ('name' => 'f77', > 'lder' => 'F77LD', > 'ld' => '$(F77)', > 'pure' => 1, > -'extensi

bug#8526: [GNU Bison 2.4.588-2f658] testsuite: 74 75 76 77 78 79 80 81 82 141 149 185 186 188 189 190 191 195 247 250 287 289 291 293 295 296 297 298 299 300 301 302 304 305 306 307 310 311 failed

* Jim Meyering wrote on Wed, Apr 20, 2011 at 02:43:46PM CEST: > [TL;DR using automake.git, bison.git fails "make distcheck"s non-srcdir build] > >> /bin/sh ../build-aux/ylwrap ../src/scan-skel.l lex.yy.c src/scan-skel.c -- > >> flex > >> /w/bison/bison-2.4.593-a78a/_build/tests/bison: line 11: >

bug#8508: 8 test failures on Fedora 15

Hi Jim, * Jim Meyering wrote on Sat, Apr 16, 2011 at 11:59:33AM CEST: > Subject: [PATCH] depcomp: correct invalid sed invocation > > * lib/depcomp: Insert missing -e before '/:$/d'. > Otherwise, that use of sed would treat '/:$/d' as a file name. Thanks. Merged from the 'fix-depcomp' branch int

bug#8483: missing serial number in soem automake-provided m4 files

* Stefano Lattarini wrote on Tue, Apr 12, 2011 at 10:43:36AM CEST: > I've recently noticed that some *.m4 files in the Automake distribution > lack a serial number: > > $ cd ~/src/automake > $ grep -L '# *serial' m4/*.m4 > m4/amversion.m4 > m4/auxdir.m4 > m4/gcj.m4 > m4/install-sh.m4 >

bug#8473: depcomp bug with HP-UX cc and VPATH build

Hi Bruno, * Bruno Haible wrote on Mon, Apr 11, 2011 at 02:44:48AM CEST: > The dependencies mechanism of Automake leads to a compilation failure when > used in a VPATH build (with GNU make, of course) Actually, in this case you could have avoided this particular bug by using HP make. :-p Automak

bug#8360: distcheck-hook never called

Hello Pitamila, let's keep the mailing list in Cc:, please. I would've seen your reply earlier then. * pitam...@free.fr wrote on Mon, Apr 04, 2011 at 04:02:53PM CEST: > - "Ralf Wildenhues" a écrit : > > > > thanks for the report. > > thanks for

bug#8360: distcheck-hook never called

* Ralf Wildenhues wrote on Sat, Apr 09, 2011 at 01:11:58PM CEST: > OK to add you to THANKS for the eventual documentation patch I've yet to > write? Can we have a full name for that too?

bug#8434: java: cannot use JAVA with both dist_ and nodist_ prefixes

Hi Stefano, * Stefano Lattarini wrote on Wed, Apr 06, 2011 at 09:00:32PM CEST: > Currently, limitations in the Automake support for java enforce the > restriction that only one `_JAVA' primary can be used in a given > Makefile.am. > This bug is particularly annoying because *.java files listed wi

bug#8449: automake-1.11.1 make check failure

close 8449 thanks Hello Thomas, * Thomas Schulz wrote on Fri, Apr 08, 2011 at 04:47:58PM CEST: > Building automake-1.11.1 on a Solaris 8 Sparc machine. With autoconf 2.68, > gnum4 1.4.15, gawk 3.1.8 & perl 5.8.5. > Make check had one failure in all.test. The log output is: > > XFAIL: all.test (e

bug#8168: macros directory not created automatically

* Stefano Lattarini wrote on Fri, Apr 01, 2011 at 03:13:19PM CEST: > On Friday 01 April 2011, Ralf Wildenhues wrote: > > Patch 2: > > - Should `--install -I foo/bar/m4' create intermediate directories, or > > would we suspect a typo? > > > I'd say the l

bug#8168: macros directory not created automatically

* Stefano Lattarini wrote on Mon, Mar 14, 2011 at 08:44:03PM CET: > > > Attached is a patch series (2 patches) that should address the issue. > The series i

bug#8365: 3 of 657 tests failed

* Stefano Lattarini wrote on Thu, Mar 31, 2011 at 02:54:36PM CEST: > At this point I'm not anymore sure this is just a testsuite-related issue > -- it seems like a genuine bug in Automake-generated remake rules. WDYT? No. You were right originally. The tests do need to $sleep. Please commit you

bug#8365: 3 of 657 tests failed

* Stefano Lattarini wrote on Wed, Mar 30, 2011 at 06:10:23PM CEST: > Now, why is configure not re-run? Here is my (longish) tentative explanation, > step by step. In what follows, I'll use the abbraviation `TS(f)' to indicate > the timestamp (i.e. last modification time) of the file `f'. > > 01.

bug#8326: can't override dvi: target, or others with -local

Hi Karl, Stefano, * Stefano Lattarini wrote on Wed, Mar 23, 2011 at 09:28:52PM CET: > On Wednesday 23 March 2011, Karl Berry wrote: > > (Aside: I'm just curious, what can dvi-local actually be used for? > > If there's a known use for it, I suggest mentioning it in the doc.) > > > If there is a kno

bug#8360: distcheck-hook never called

Hello Pitamila, thanks for the report. * pitam...@free.fr wrote on Mon, Mar 28, 2011 at 09:17:09AM CEST: > I'd like to make a rpm buildpackage in my distcheck-hook rule. > My 'distcheck-hook' rule in my root Makefile.am is never called. > I tryed to define a 'distcheck-local' too without success.

bug#8362: make install prefix inserted in source code with generated python files

Hello, * A.T.Hofkamp wrote on Mon, Mar 28, 2011 at 09:36:45AM CEST: > As far as I know, "make install prefix=/path/to/writable/dir" should > only change the place where files are copied to, instead of > injecting that new prefix into the source code. However, for Python > source files that are gen

bug#8289: distcheck and make dvi

* Karl Berry wrote on Sun, Mar 20, 2011 at 10:28:59PM CET: > not bother checking dvi output and rather test PDF output seems > like another good alternative. > > I can't agree with that. That's trading DVI-generation problems for > PDF-generation problems. Believe me, there will be just

bug#8289: distcheck and make dvi

Hi Karl, thanks for the bug report. * Karl Berry wrote on Sat, Mar 19, 2011 at 12:33:14AM CET: > http://comments.gmane.org/gmane.comp.sysutils.automake.general/10304 > > I suggest that the workaround Ralf suggests there -- an empty make rule > for dvi: -- be explicitly documented. Another (ofte

bug#7833: automake uses two different values for DejaGNU srcdir

Hello Peter, all, and sorry for the delay, * Peter Breitenlohner wrote on Sat, Jan 15, 2011 at 04:22:32PM CET: > On Fri, 14 Jan 2011, Ralf Wildenhues wrote: > > >Through testing I found out again that DejaGNU does not cope with white > >space in absolute directory names any

bug#8099: LaTeX and automake

* Reuben Thomas wrote on Thu, Mar 03, 2011 at 04:42:33PM CET: > > Thoughts? We could just provide thin-layer support for both latexmk and/or rubber. That would probably be the least amount of work, both inside Automake, and for getting any missing bits into the upstream projects. Thanks, Ralf

bug#8099: LaTeX and automake

I just learned about rubber which also aims to deal with latex documents. Have you looked at it yet? Thanks, Ralf

bug#8099: LaTeX and automake

Hi Reuben, * Reuben Thomas wrote on Mon, Feb 28, 2011 at 03:24:57PM CET: > Update: I've written to John to ask about copyright assignment, but > discovered in the mean time that there are one or two other authors to > talk to. I will see what John says first before considering how to > proceed. I

bug#8125: Automake

close 8125 thanks Hello David, thanks for the report. * David Lisle wrote on Sat, Feb 26, 2011 at 08:33:08PM CET: > There were four messages, however I failed to capture all four. Here > is the output file from "Make check" > FAIL: exdir2.test > FAIL: man2.test > FAIL: subst.test > FAIL: transf

bug#8099: LaTeX and automake

* Reuben Thomas wrote on Sun, Feb 27, 2011 at 02:39:31PM CET: > On 27 February 2011 06:53, Ralf Wildenhues wrote: > > Anyway, the next step to pursue this would be to think hard about the > > desired semantics, > > The tricky part here is that latexmk does its own dependen

bug#8076: PCH support / howto

severity 8076 wishlist thanks Hello Olaf, * Olaf van der Spek wrote on Thu, Feb 24, 2011 at 12:53:19PM CET: > > I just read http://sources.redhat.com/automake/automake.html#Examples > > but didn't find anything on PCH. > > Would it be possible to include a 'Hello World' style use of PCH? > > Som

bug#8099: LaTeX and automake

Hello Reuben, * Reuben Thomas wrote on Tue, Feb 22, 2011 at 10:43:51PM CET: > I have just been investigating the state of the art for LaTeX support. > I've just been autotooling up an old build system of mine from 15 > years ago, and needed to build several LaTeX documents of modest > complexity,

bug#8104: automake suggests use of AC_PROG_LIBTOOL, this has been replaced by LT_INIT

* Stefano Lattarini wrote on Sat, Feb 26, 2011 at 02:54:09PM CET: > Fine with me. This is the additional squash-in -- on the top of the old > one, since I had already commited that locally :-( Don't worry, I do such junk commits all the time. You could git diff HEAD@{2} or some similar comman

bug#8104: automake suggests use of AC_PROG_LIBTOOL, this has been replaced by LT_INIT

mmyes, we have a lot of old pending stuff unfortunately ... > On Saturday 26 February 2011, Ralf Wildenhues wrote: > > * Stefano Lattarini wrote on Thu, Feb 24, 2011 at 10:45:11AM CET: > > LT_PREREQ has been introduced in 1.9b only. Also, I > > think that if the LT_PREREQ

bug#8104: automake suggests use of AC_PROG_LIBTOOL, this has been replaced by LT_INIT

* Stefano Lattarini wrote on Thu, Feb 24, 2011 at 10:45:11AM CET: > I agree with Jack that advertising the use of LT_INIT would be better, > since, according to Libtool NEWS file, that has obsoleted AC_PROG_LIBTOOL > since version 1.9b (2004-08-29). Yes. There are still 1.5.x users out there, but

bug#8111: after adding a(nother) subconfigure, rerunning make fails

Hi Stefano, * Stefano Lattarini wrote on Sat, Feb 26, 2011 at 09:32:57AM CET: > On Saturday 26 February 2011, Ralf Wildenhues wrote: > > This is not an Automake bug after all. It can be solved completely > > within Autoconf, thus no new version skew danger. :-) > > > Wha

bug#8111: after adding a(nother) subconfigure, rerunning make fails

close 8111 thanks This is not an Automake bug after all. It can be solved completely within Autoconf, thus no new version skew danger. :-) Patch for Autoconf coming up. Thanks, Ralf

bug#8111: after adding a(nother) subconfigure, rerunning make fails

[ adding autoconf-patches; this is <http://debbugs.gnu.org/8111> ] * Jack Kelly wrote on Thu, Feb 24, 2011 at 11:49:44PM CET: > On Fri, Feb 25, 2011 at 6:36 AM, Ralf Wildenhues wrote: > > Can we fix this somehow in either Autoconf or Automake? > > Could we save t

bug#8111: after adding a(nother) subconfigure, rerunning make fails

Say I have a project with an up to date build tree. Say I add a(nother) sub package, update toplevel configure.ac, then rerun make. Then the new sub/configure will not be rerun by the triggered './config.status --recheck' thus make will later fail due to nonexistent Makefile in the new subdirecto

bug#7995: [PATCH 3/4] Guile macro AM_PATH_GUILE.

(+), 2 deletions(-) create mode 100644 m4/guile.m4 diff --git a/ChangeLog b/ChangeLog index 5483ce4..bd27a05 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,9 @@ 2011-02-20 Ralf Wildenhues + Guile macro AM_PATH_GUILE. + * m4/guile.m4 (AM_PATH_GUILE): New file, new macro

bug#7995: [PATCH 4/4] Implement Guile support.

--git a/ChangeLog b/ChangeLog index bd27a05..bff6c15 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,13 @@ 2011-02-20 Ralf Wildenhues + Implement Guile support. + * automake.in: Register new language 'Guile'. + (handle_guile): New function. + (generate_makefile): Ca

bug#7995: [PATCH 2/4] Testsuite coverage for Guile support.

create mode 100755 tests/guile3.test create mode 100755 tests/guile4.test diff --git a/ChangeLog b/ChangeLog index c338e8a..5483ce4 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,10 @@ 2011-02-20 Ralf Wildenhues + Testsuite coverage for Guile support. + * tests/guile1.test

bug#7995: [PATCH 1/4] Documentation for Guile support.

- 3 files changed, 167 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 12b8e9f..c338e8a 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2011-02-20 Ralf Wildenhues + + Documentation for Guile support. + * doc/automake.texi (Guile): New

bug#7995: Guile support in Automake

[ http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7995 aka http://thread.gmane.org/gmane.comp.sysutils.automake.bugs/5303 ] * Ralf Wildenhues wrote on Sun, Feb 06, 2011 at 11:22:57PM CET: > Automake should support Guile. > I actually have patches for some tests, documentation and h

bug#8044: Automake should support autotest-based testsuites.

Hello, * Eric Blake wrote on Tue, Feb 15, 2011 at 07:44:06PM CET: > > It sounds useful for some (probably not me, though), but I'd be wary > > of the big warning at the start of the autotest section: > > > >>> N.B.: This section describes a feature which is still > >>> stabilizing. Although we b

bug#8022: use .MAKEFILEDEPS for FreeBSD make

Severity: wishlist Similar to GNU make, which by default causes the makefile and included files to be rebuilt before doing anything else, FreeBSD make can do alike, when the special target .MAKEFILEDEPS exists. I've only checked FreeBSD 7.1 manpages for this feature. We could be using this for r

bug#7995: Guile support in Automake

Automake should support Guile. (From Ludovic Courtès and Andy Wingo). I actually have patches for some tests, documentation and half an implementation from last year; opening this PR now to track progress and not forget again. Thanks, Ralf

bug#7994: make distcheck fails when latex is not installed

In a package with a texinfo file, distcheck fails when LaTeX is not installed. Instead, it should exit 63(?). The fact that distcheck runs 'make dvi' is not documented. (From Jose; please correct me if I cited this wrongly now.) Thanks, Ralf

bug#7849: new instspc* test failures

* Ralf Wildenhues wrote on Sun, Jan 16, 2011 at 09:46:26AM CET: > On Cygwin, instspc-dotdotdot-build.test fails because executing a COFF > binary in a directory named '...' fails (causing the "compiler works" > test to fail at configure time): > > $ mkdir ..

bug#7945: Is AM_PATH_PYTHON missing some versions in _AM_PYTHON_INTERPRETER_LIST?

Hello Jack, * Jack Kelly wrote on Mon, Jan 31, 2011 at 12:14:22AM CET: > While poking around python.m4, I noticed that python2.6 and python2.7 > are not mentioned in the list of python interpreters defined in > _AM_PYTHON_INTERPRETER_LIST. Is this intentional? This is fixed in git Automake (both

bug#7884: [PATCH] yacc: fix VPATH builds with FreeBSD make

* Stefano Lattarini wrote on Fri, Jan 28, 2011 at 01:51:40PM CET: > On Thursday 27 January 2011, Ralf Wildenhues wrote: > > Does 'make -n' create files (for any target)? > > > No, and I've updated the `yaccdry.test' testcase to also check for this > (see a

bug#7884: Yacc and FreeBSD make in VPATH builds

* Stefano Lattarini wrote on Thu, Jan 27, 2011 at 08:26:42PM CET: > On Thursday 27 January 2011, Ralf Wildenhues wrote: > > I must admit that I still don't like this a lot. BSD is free software, > > we shouldn't have to put ugly workarounds in place for it, and this >

bug#7884: Yacc and FreeBSD make in VPATH builds

* Stefano Lattarini wrote on Thu, Jan 27, 2011 at 11:54:50AM CET: > On Tuesday 25 January 2011, Ralf Wildenhues wrote: > > * Stefano Lattarini wrote on Tue, Jan 25, 2011 at 08:52:56PM CET: > > > Hmm... maybe a variation of this might be a good solution after all, at > >

bug#7922: 1.11 doesn't add sources with nonstandard suffixes when making a binary

Hello Юрий, please, do not top-post on this list. Thank you. * Юрий Пухальский wrote on Wed, Jan 26, 2011 at 11:23:42AM CET: > 2011/1/11 Ralf Wildenhues: > > * Юрий Пухальский wrote on Tue, Jan 11, 2011 at 03:48:08PM CET: > >> .SUFFIXES: .pc .lo .c > >> .pc.c: >

bug#7884: Yacc and FreeBSD make in VPATH builds

* Stefano Lattarini wrote on Tue, Jan 25, 2011 at 08:52:56PM CET: > On Saturday 22 January 2011, Ralf Wildenhues wrote: > > > > > - Tell the developer to add proper AC_CONFIG_LINKS to configure in > > >order to support VPATH builds with FreeBSD make (yuck^2, since

bug#7893: HP-UX make causes autoconf timestamp issues

http://autobuild.josefsson.org/automake/log-201101181921247117000.txt This HP-UX 11.31 system is fast enough to trigger test failures for at least these Automake tests, besides the ones already fixed: insthook libobj16b output10 posixsubst-data posixsubst-scripts subcond2 subpkg2 suffix13 all due

bug#7892: test failures induced by stale NFS files on Solaris

http://autobuild.josefsson.org/automake/log-201101181921337961000.txt http://autobuild.josefsson.org/automake/log-201101181921319021000.txt I've looked a bit now, and two of the leftover NFS files I could find were configure and install-sh. These failures are not new, see this older report: http:/

bug#7868: splitting up test suites

Hi Stefano, * Stefano Lattarini wrote on Thu, Jan 20, 2011 at 10:19:24PM CET: > On Thursday 20 January 2011, Ralf Wildenhues wrote: > > * Stefano Lattarini wrote on Thu, Jan 20, 2011 at 12:38:17PM CET: > > > Hmmm... while this feature might be worth having even indipendently &g

bug#7621: add a way to pass link dependencies

[ http://thread.gmane.org/gmane.comp.sysutils.automake.bugs/5122 ] Hi Bruno, first off, thanks for the very nice and detailed report, and sorry for the delay. * Bruno Haible wrote on Sun, Dec 12, 2010 at 03:43:00PM CET: > When creating an executable or library, sometimes other libraries > have t

bug#7884: Yacc and FreeBSD make in VPATH builds

* Stefano Lattarini wrote on Fri, Jan 21, 2011 at 10:28:24PM CET: > - Always create yacc-derived and distributed .c and .h files in >$(srcdir), and explicitly instruct make to alwsys look fr them >there at first -- similarly to what is done for info files >(yuck) Yes, this is ugly, bu

bug#7868: splitting up test suites

Hi Stefano, * Stefano Lattarini wrote on Thu, Jan 20, 2011 at 12:38:17PM CET: > On Wednesday 19 January 2011, Ralf Wildenhues wrote: > > We've finally reached the point where we have more than 1000 > > tests, $(TESTS) expands to 15k characters, and where 'make check'

bug#7868: splitting up test suites

The testsuite is too large for MSYS. We've finally reached the point where we have more than 1000 tests, $(TESTS) expands to 15k characters, and where 'make check' will not work at all any more on MSYS, because it cannot spawn sh any more, presumably in 'make check TESTS="..."'. (MSYS make doesn'

bug#7864: odd configure bug with dependency checking and conditional C++ support

Fixed by v1.11-293-gd652a1c.

bug#7860: recursive autoreconf breaks AM_COND_IF conditionalization of AC_CONFIG_FILES

* Dave Hart wrote on Tue, Jan 18, 2011 at 10:13:21PM CET: > When invoked by autoreconf of a project with nested configure.ac > files, automake does not respect the disabling of AC_CONFIG_FILES by > the top-level configure.ac using AM_COND_IF, resulting in an incorrect > Makefile. Re-running autore

bug#7860: recursive autoreconf breaks AM_COND_IF conditionalization of AC_CONFIG_FILES

* Dave Hart wrote on Tue, Jan 18, 2011 at 10:13:21PM CET: > http://support.ntp.org/people/hart/am-libopts-subpkg.tar.gz First off, here's a trivial portability fix from that tarball. Cheers, Ralf 2011-01-19 Ralf Wildenhues * m4/liboptschk.m4 (ag_FIND_LIBOPTS): Avoid bashis

bug#7864: odd configure bug with dependency checking and conditional C++ support

[ adding automake-patches, dropping bug-gnulib ] Hi Eric, thanks for the report! * Eric Blake wrote on Wed, Jan 19, 2011 at 05:52:08AM CET: > checking dependency style of :... mkdir: cannot create directory > `conftest.dir': File or Directory already exists > cp: accessing `conftest.dir': Bad da

bug#7862: Cygwin test failure of parallel-am.test

On Cygwin, parallel-am.test fails with a segmentation fault in an automake invocation in the last loop of the test, here's the stackdump: Exception: STATUS_ACCESS_VIOLATION at eip=610F2804 eax=FFD8 ebx=118E6800 ecx=118E9800 edx=118E67E0 esi=118DE828 edi=9028 ebp=118E67D8 esp=027BC330 progr

bug#7849: new instspc* test failures

There are a number of new failures since the splitup of instspc.test. Most seem to stem from increased coverage. Rather than putting each failure in a different PR, I'm listing a number of them here; we can still split things out further later if that proves necessary. On MinGW, instspc-carriage

bug#7833: automake uses two different values for DejaGNU srcdir

* Ian Lance Taylor wrote on Thu, Jan 13, 2011 at 06:29:39PM CET: > Ralf Wildenhues writes: > > > Am I correct in assuming that it is hopeless to assume GCC will work > > when either values are relative? > > Actually, as far as I know, GCC is likely to work with a relativ

bug#7833: automake uses two different values for DejaGNU srcdir

Hello Ian, thanks for the bug report. * Ian Lance Taylor wrote on Wed, Jan 12, 2011 at 10:52:09PM CET: > When automake is configured to use DejaGNU, it uses two different values > for srcdir. There are two different cases in lib/am/dejagnu.am: > check-DEJAGNU: site.exp > ## Life is easiest with

bug#7828: documentation about '-d' in AM_YFLAGS is suboptimal

* Stefano Lattarini wrote on Wed, Jan 12, 2011 at 01:36:08PM CET: > On Wednesday 12 January 2011, Юрий Пухальский wrote: > > Package isn't enclosed because otherwise the message doesn't get through. > > > > > Finally had time to make some tests, and now i've got it:) > > > > > > When i set AM_YFLA

bug#7824: 1.11 doesn't add sources with nonstandard suffixes when making a binary

Hello Юрий, * Юрий Пухальский wrote on Tue, Jan 11, 2011 at 03:48:08PM CET: > I've (finally) made it through two implicit rules, but i have a problem there. > > The makefile looks something like that: > > > .SUFFIXES: .pc .lo .c > .pc.c: > cp $< $@ > .c.lo: >

bug#7819: automake does not really automatically distribute all the files it's advertised to.

* Stefano Lattarini wrote on Mon, Jan 10, 2011 at 10:40:13PM CET: > On Monday 10 January 2011, Ralf Wildenhues wrote: > > * Stefano Lattarini wrote on Mon, Jan 10, 2011 at 08:50:13PM CET: > > > But the above is not always correct, as some of these files are > > > distri

bug#7819: automake does not really automatically distribute all the files it's advertised to.

Hi Stefano, * Stefano Lattarini wrote on Mon, Jan 10, 2011 at 08:50:13PM CET: > Files which are automatically distributed, if found: > ABOUT-GNU README config.rpathltcf-gcj.sh > ABOUT-NLS THANKS config.sub ltconfig > AUTH

bug#7766: (lack of) config.h description in manual

retitle 7766 docs: work on index issues thanks * Karl Berry wrote on Sat, Jan 01, 2011 at 01:00:20AM CET: > > Subsidiary points: in the general index (I continue to very strongly > encourage you to merge all indexes, BTW), I didn't find anything useful > for "preprocessor", or "#define", or "conf

bug#7766: (lack of) config.h description in manual

Hi Karl, * Karl Berry wrote on Sat, Jan 01, 2011 at 01:00:20AM CET: > Finally, the "amhello explained" node is pretty long. It seems to break > up naturally into three pieces, for each of the files being explained. > Perhaps it would be good to make them each separate (sub)nodes. Hmm, I see a na

bug#7800: automake fails to honor `-d' in AM_YFLAGS when variable expansions are involved

* Ralf Corsepius wrote on Sat, Jan 08, 2011 at 04:26:11AM CET: > On 01/07/2011 07:53 PM, Ralf Wildenhues wrote: > >* Ralf Corsepius wrote on Fri, Jan 07, 2011 at 05:52:54PM CET: > >>On 01/07/2011 03:36 PM, Stefano Lattarini wrote: > >>>Currently, automake is not sm

bug#7773: (lack of) config.h description in manual

As part of addressing Automake bug#7766 and bug#7773, I'm pushing the following in Karl's name, to the maint branch. Cheers, Ralf 2011-01-08 Karl Berry Eric Blake docs: reference defining directories in amhello node. * doc/automake.texi (amhello Explained): Point

bug#7800: automake fails to honor `-d' in AM_YFLAGS when variable expansions are involved

Hi Stefano, thanks for the report. * Stefano Lattarini wrote on Fri, Jan 07, 2011 at 03:36:43PM CET: > Currently, automake is not smart enough to resolve variable expansions > in AM_YFLAGS (or foo_YFLAGS) when scanning them for the `-d' flag. value_as_list_recursive can usually help here. > Not

bug#7773: (lack of) config.h description in manual

Hello Jack, * Jack Kelly wrote on Tue, Jan 04, 2011 at 03:53:44PM CET: > I disagree that `make prefix=... install' is a poor man's DESTDIR. OK ok, I didn't mean to offend anyone here. > Installing using DESTDIR will install things in > $(DESTDIR)/$(prefix)/bin (and so on), which is a right pain

bug#7773: (lack of) config.h description in manual

Hello Karl, Eric, * Eric Blake wrote on Tue, Jan 04, 2011 at 01:33:42AM CET: > On 01/03/2011 05:00 PM, Karl Berry wrote: > > Thanks for the reference. Now that I know it, I suggest the Automake > > manual simply have a sentence with an xref to that node. Yes, I agree with that, and I am still go

bug#7773: (lack of) config.h description in manual

Hi Karl, * Karl Berry wrote on Mon, Jan 03, 2011 at 01:17:00AM CET: > Following up to my own mail, No. :-) This opened a new bug report. I'm closing it, for reasons explained below. > it seems I have been missing something > basic all these years, since it's never come up in my own packages:

bug#7763: Remake rules botch up when 'foreign' and 'ignore-deps' are removed from AM_INIT_AUTOMAKE

* Stefano Lattarini wrote on Sun, Jan 02, 2011 at 12:00:56PM CET: > On Sunday 02 January 2011, Ralf Wildenhues wrote: > > Question is, does removing the arguments break other, legitimate uses? > > Or was this functionality purely added at a time before automake could > > trac

bug#7763: Remake rules botch up when 'foreign' and 'ignore-deps' are removed from AM_INIT_AUTOMAKE

Hello Stefano, * Stefano Lattarini wrote on Thu, Dec 30, 2010 at 11:38:45PM CET: > Currently, the Automake-generated rebuild rules[1] invoke automake with > some command-line options derived from arguments given to AM_INIT_AUTOMAKE. > > [1] For more info, see: >

bug#7657: TEXINFOS and MANS primaries accepts too many prefixes

* Stefano Lattarini wrote on Tue, Dec 21, 2010 at 01:55:39PM CET: > On Sunday 19 December 2010, Ralf Wildenhues wrote: > > * Stefano Lattarini wrote on Fri, Dec 17, 2010 at 12:19:40PM CET: > > > xmandir = $(mandir) # we want info files installed in

bug#7671: Presetting various *CLEANFILES variables

Hello Behdad, and thanks for the bug report, * Behdad Esfahbod wrote on Sat, Dec 18, 2010 at 01:55:22AM CET: > If instead automake was changed to always pre-initialize *CLEANFILES > variables, all snippets could just append to do variables and my git.mk > snippet would be more generic and much mor

bug#7673: Bad option precedence: AM_AUTOMAKE_INIT and AUTOMAKE_OPTIONS might win over command line

* Stefano Lattarini wrote on Sat, Dec 18, 2010 at 03:12:17PM CET: > Currently, the strictness-related options specified with AM_INIT_AUTOMAKE > in configure.ac and with AUTOMAKE_OPTIONS in Makefile.am win over those > specified on the command line: > While this behaviour might have had its histori

bug#7669: option "foreign" after "-Wall" turns off and portability warnings.

* Stefano Lattarini wrote on Fri, Dec 17, 2010 at 07:52:29PM CET: > With automake >= 1.10, foreign *after* -Wall in AM_INIT_AUTOMAKE turns > off portability warnings. > While the current behaviour is due to various historical and implementation > reasons, IMHO it is counter-intuitive and somewhat

bug#7657: TEXINFOS primary accepts too many prefixes.

* Stefano Lattarini wrote on Fri, Dec 17, 2010 at 12:19:40PM CET: > On Friday 17 December 2010, Ralf Wildenhues wrote: > > For example, I can easily imagine a package having normal texinfo > > manuals, but also a developer's manual that maybe should end up > > in an in

bug#7670: About make implementations that don't chain implicit rules

* Stefano Lattarini wrote on Fri, Dec 17, 2010 at 11:52:17PM CET: > Currently, automake is quite smart in catching and taking into account > possible chaining of implicit rules. [...] > And here comes the problem. While the above example works correctly for > at least GNU make (tested with versio

bug#7661: docs: typo in documentation about python extension modules?

* Stefano Lattarini wrote on Fri, Dec 17, 2010 at 02:51:12PM CET: > pyexec_LTLIBRARIES = quaternion.la > quaternion_SOURCES = quaternion.c support.c support.h > quaternion_la_LDFLAGS = -avoid-version -module > Shouldn't `quaternion_la_SOURCES' be used instead of `quat

bug#7656: MANS primary accepts too many prefixes.

* Stefano Lattarini wrote on Thu, Dec 16, 2010 at 10:51:15PM CET: > Currently, the MANS primary accept *all* the standard automake > builtin prefix dirs (from lib and bin to pkglibexec and sysconf). > > IMHO it should accept only man and man{1..9} (maybe doc? but I'd > rather say no). This one is

bug#7657: TEXINFOS primary accepts too many prefixes.

* Stefano Lattarini wrote on Thu, Dec 16, 2010 at 10:52:10PM CET: > Currently, the TEXINFOS primary accept *all* the standard automake > builtin prefix dirs (from `lib' and `bin' to `pkglibexec' and > `sysconf'). > > IMHO it should accept only the `info' prefix (maybe also `doc'? but > I'd rather

bug#7655: conditional _TEXINFOS should be supported

[ no need to keep bug-automake@ in Cc:; debbugs takes care of that ] Hello Jack, * Jack Kelly wrote on Thu, Dec 16, 2010 at 08:42:52PM CET: > On Fri, Dec 17, 2010 at 6:41 AM, Jack Kelly wrote: > > On Fri, Dec 17, 2010 at 6:09 AM, Ralf Wildenhues wrote: > >> if COND > >&g

bug#7654: docs: is LTLIBRARIES missing from the list of primaries in the automake manual?

* Stefano Lattarini wrote on Thu, Dec 16, 2010 at 06:40:37PM CET: > In section "3.3 The Uniform Naming Scheme" I read: > > ``The current primary names are ‘PROGRAMS’, ‘LIBRARIES’, ‘LISP’, >‘PYTHON’, ‘JAVA’, ‘SCRIPTS’, ‘DATA’, ‘HEADERS’, ‘MANS’, and >‘TEXINFOS’. Some primaries also allow a

  1   2   3   4   5   6   >