Re: automake.texi and @acronym

I'm okay with changing the m4 and autoconf manuals with s/@acronym{GNU}/GNU/ s/@acronym{(.*)}/\1/ if we agree that it is easier to maintain, Is to me. and doesn't buy much typographically. I think having the (minor) benefit of consistency between GNU manuals outweighs the

Re: automake.texi and @acronym

What about @sc{gnu}, which also appears in some but not all GNU manuals? In terms of logical markup, @sc should definitely not be used. Typographically, I greatly dislike it (in running text) as well. Is there any difference between @acronym and @sc? Yes. @sc is small caps (=x-height

Re: automake.texi and @acronym

Hi Simon, Is the intention that even the n...@acronym{gnu} cases should be replaced? Then what purpose is the @acronym keyword for? I wrote about that earlier. Minor typographic change which is rarely used in GNU manuals. De facto standard is not to use it. Which is also simpler in

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

Following up to my own mail, it seems I have been missing something basic all these years, since it's never come up in my own packages: in order to use the directory variables like $(LIBDIR) in the code, it seems each package has to hack them in to config.h, e.g., via gnulib's configmake module.

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

Hi Ralf, I'm closing it, for reasons explained below. And I'm reopening it, maybe. Not too clear on debbugs interactions. No, I do not think that automake.info should repeat all of autoconf.info information. Me either. I don't ever intend to suggest creating such redundancy.

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

Hmm, I see a natural split into two, not three nodes. Ok, fine. Below, I replaced the existing one rather than using another lower hierarchy level. Does this seem acceptable to you? Sure, but I suggest making the @node names closer to the @section names, and not using that

bug#8289: distcheck and make dvi

However, there are cases where dvi output just isn't feasible in practice. Yep. Therein lies the essence of the problem. 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

bug#8289: distcheck and make dvi

Hi Jack, New automake options? Something like: I like my idea of a variable better :). Seems simpler/less intrusive/more general. Best, k

bug#11803: missing:138 has trailing whitespace

I saw there has been some discussion on bug-gnulib about removing missing and some of the other internal autotools helper scripts from gnulib. That makes sense, but I didn't see a final conclusion to the discussion? Meanwhile, I have been unable to autoupdate missing from automake to gnulib --

bug#12967: Texinfo compile failure on IRIX 6.5

I'll need access to an IRIX system to do so myself. I will ask my friend at Utah for an account for you if you want to pursue it. Let me know.

bug#13324: Improvements to dist targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)

That is already possible: http://www.gnu.org/software/automake/manual/automake.html#The-dist-Hook I see. Given this, I propose merely changing the definition of am__tar to use variables. Something like: am__tar = $(TAR) $(TAR_OPTIONS) - $$tardir where the actual definitions of TAR and

bug#13324: Improvements to dist targets (was: Re: EXTRA_DIST, directories, tar --exclude-vcs)

OTOH, what about distribution tarballs in '.zip' format? They don't use tar at all ... Time to deprecate them maybe? Is anybody actually using them? And while at it, what about the even more obscure 'shar' format? FWIW, I think they should still be supported. I see recent

Re: formatting in gnupload

| You may _not_ leave the `do' on the same line as `for', since some | shells improperly grok: | | for arg; do How depressing that we have to uglify our sources merely to cater to a badly broken proprietary /bin/sh. Oh well. Thanks for the info.

Re: GNITS being referenced, with no link...

Personally, I'd be happy if gnits disappeared from automake completely, except for being invisibly implemented as a synonym for `gnu'. Does it really serve a purpose any more? Even those of us who were/are part of the actual gnits group no longer use that option. Thanks, Karl

gnupload and delete

It is not exactly simple to figure out how to delete (archive) files from ftp.gnu.org and alpha.gnu.org with the ftp directives, and anyway constructing the directive files and uploading them by hand is always a pain. This patch adds a --delete option so gnupload can do it. It worked ok in my

gnupload self-url?

I was thinking it might be useful for gnupload --help to tell users (i.e., maintainers) how to get the latest version of the script. Wdyt? --- /u/karl/gnu/src/automake/lib/ORIG/gnupload 2008-11-13 08:10:36.0 -0800 +++ /u/karl/gnu/src/automake/lib/gnupload 2009-01-29

Re: gnupload improvements

I do with we had some testsuite exposure for gnupload though, this has grown so complicated that bugs are likely. Is there test upload space on some of these hosts? Sergey's new upload to a directory functionality is probably the best way to do tests. That's essentially what I did

Re: gnupload improvements

Hmm, then I guess I don't like those options either; but also I don't like backward incompatibilities. Sigh. Since gnupload is only used by GNU maintainers, I do not consider backward compatibility as critical as with normal programs. I don't feel strongly about --symlink arg parsing.

gnupload --help plural

Minor tweak, edit or ignore as you like. I left out the update to scriptversion and the copyright year ... Karl Berry k...@gnu.org * gnupload (usage): Shorten to make more likely to fit on a tty line. Mention CMD in the synopsis. With ..., plural is implied. --- /tmp

mdate-sh help msg

Suggestion for mdate-sh's --help message. Obviously this is really crucial and urgent stuff :). Thanks, karl Karl Berry k...@gnu.org * mdate-sh: mention actual output format in help msg. --- orig/mdate-sh 2009-05-18 00:52:20.0 -0700 +++ new/mdate-sh2010-02-21

hello uses fdl.texi, not gpl.texi

Some time ago I changed hello.texi to not @cinlude gpl.texi any more. May as well fix the example in the Automake manual. Diff below. --- /tmp/ORIG/automake.texi 2010-02-25 00:22:09.0 -0800 +++ /tmp/automake.texi 2010-03-06 15:15:17.0 -0800 @@ -7743,3 +7743,3 @@ file. For

Re: New auxiliary archive script

could you please adjust your scripts to also autoupdate the 'ar-lib' script from Automake to Gnulib, Sure, done. Tx.

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

You mean without a description added afterwards in the @menu, right? Right. Fine with me, the only small bummer is that emacs ^C ^U ^V then generates trailing white space in the menus; oh well. Was once considered a feature ... don't know if it's been raised recently with bug-emacs.

Re: bug#11146: texinfo: could automake start using the '--tidy' option in its dvi and pdf rules?

Since the '--tidy' option has only been introduced in Texinfo 4.9 More ordinary English syntax would be: Since the '--tidy' option was introduced in Texinfo 4.9 (Though the meaning is clear in the original.) The users should be warned about the planned behavioural change I have

doc patch for dist-hook reference

read this text and never thought of going further :(. 2013-01-03 Karl Berry k...@gnu.org * automake.texi (Basics of Distribution): mention dist-hook as working around the problems of whole directories in EXTRA_DIST. --- /tmp/ORIG/automake.texi 2013-01-03 00:25:08.0

Re: doc patch for dist-hook reference

Could you re-post this as a patch produced by git format-patch? Not without formatting it that way by hand; actually using git is incomprehensible to my brain, sorry, and I don't want to take the time to do it manually for two sentences. If it's not worth it to you either, just ignore the

Re: [PATCH] docs: mention dist-hook help for EXTRA_DIST

I didn't mind taking 3 minutes to convert this into a git commit. Thanks. +ameliorate the problem; @xref{The dist Hook}. I'm afraid that's the wrong kind of xref (capital See). Needs to be @pxref.

bug#20713: aclocal/tar.m4 and solaris 5.10

Running a configure script on solaris 5.10 generated with automake-1.15, I got these errors about id, which being pre-POSIX, does not support -u: id: illegal option -- u Usage: id [-ap] [user] id: illegal option -- g Usage: id [-ap] [user] checking whether UID

bug#32074: maintainer-clean and removing configure/Makefile.in/etc.

I think Automake shouldn't suggest something that is explicitly discouraged by the GCS. Good point. I agree. I would suggest discussing it on ... Perfectly reasonable, but I'm just too old to have the stomach for those discussions any more :(. Hardly the most crucial suggestion in

bug#32074: maintainer-clean and removing configure/Makefile.in/etc.

Hi Mathieu, Thanks for the quick reply. What is not clear to me is the reasoning of that heuristic. You seems to suggest that it has been introduced to avoid having to know the order in which autoconf, aclocal, automake, ... has to be run. Have you any reference regarding that?

bug#36921: texinfo: @setfilename is not mandatory

I posted a patch to fix this issue: https://lists.gnu.org/archive/html/bug-automake/2019-01/msg2.html Thanks Gavin. I hope Jim (Meyering) or I will install the patch soon, although the timing of the next release is unknown at this point. I'm just starting to get a grip on the

bug#36966: install-sh -s on 555 executable fails

(I'm not on this list, so please keep me in cc if need be.) It seems that install-sh -s (what automake's install-strip target can end up doing) fails if the original file doesn't have the owner-write bit set: cp /bin/cp /tmp/rx# any binary will do chmod 555 /tmp/rx # make

bug#38139: Fwd: Likely bug: generating tags with Emacs Lisp sources present

Hi Luca - not that I am an official automake maintainer, but thanks for the report, and sorry for the lack of response. Your fix looks right to me, FWIW. I hope Jim or I or someone will commit it soon. Creating the test case will surely consume the most time. If you can easily make a minimal

bug#32088: Python >=3.5 test suite failures

Hi Andreas, Lukas, and all - I have pushed Lukas's two patches, tweaked per Andreas's subsequent fixes, and also adjusted for the current sources. Hope it flies, please reopen if problems. Thanks to all! --karl

Re: Fix python3 deprecation warning

Hi Gabriel - back on your patch from last July (sorry): https://lists.gnu.org/archive/html/automake-patches/2019-07/msg2.html replace the imp functions with the new ones from importlib. ... -import sys, os, py_compile, imp +import sys, os, py_compile, importlib I

Re: bug#35848: Should automake use gmake by default if exists?

Hi Libor - back on your improvement to the failed dependency tracking message, from last May (sorry): From: Libor Bukata Date: Thu, 23 May 2019 12:31:31 +0200 ... +AC_MSG_FAILURE([Something went wrong during bootstrapping of makefile +fragments for automatic dependency

bug#35848: Should automake use gmake by default if exists?

Hi Libor - back on your improvement to the failed dependency tracking message, from last May (sorry): From: Libor Bukata Date: Thu, 23 May 2019 12:31:31 +0200 ... +AC_MSG_FAILURE([Something went wrong during bootstrapping of makefile +fragments for automatic dependency

Re: [PATCH] Support for Flang and ARM HPC compiler

Hi Paul - back on this patch for flang from last February (sorry), is this still the right thing to do? Thought I would check before applying it. Please let me know if any changes are needed now, a year later ... thanks! --karl Date: Wed, 27 Feb 2019 13:46:44 + From:

Re: [PATCH] lib/COPYING: Update from https://www.gnu.org/licenses/gpl-3.0.txt

Hi Vincent and all, Date: Mon, 7 Jan 2019 16:07:25 +0100 From: Vincent Lefevre To: automake-patches@gnu.org, vinc...@vinc17.net Subject: [PATCH] lib/COPYING: Update from https://www.gnu.org/licenses/gpl-3.0.txt This only changes URLs to use https.

Re: [PATCH] Support for Flang and ARM HPC compiler

> Hi Paul - back on this patch for flang from last February To follow up for the record: Paul replied (off-list) that there weren't any known things to change. He asked another person to look, who has not replied. But I went ahead and installed it, since it is simple and, presumably, harmless.

Re: Fix python3 deprecation warning

I would have expected your version of python to raise a warning. Maybe it's a distribution specific change ? Looks like that way. The CentOS7 packages for python3 still provide a /usr/lib64/python3.6/imp.py without any deprecation warnings that I can discern. Not that I'm sure of anything

bug#39078: Path.pm change -> deltree.pl -> t/uninstall-fail failure

t/ax/deltree.pl is used in t/ax/test-lib.sh's rm_rf_ function to recursively remove a directory tree, even given directories with zero permissions, such as intentionally created by uninstall-failsh. Version 2.15 of Perl's File::Path (released with perl-5.28.0) has changed behavior such that this

bug#39078: Path.pm change -> deltree.pl -> t/uninstall-fail failure

Regarding the new failure of Path.pm:rmtree to do removals, here is the change I had in mind to use chmod and rm instead. The previously-"ERROR" tests (uninstall-fail and instspc) work for me with this change. Before I bother spending time on all the related overhead changes, any objections,

[PATCH] tests: use find+rm, not perl, to remove temporary directories.

Here's my proposed patch to use chmod and rm -rf (again), instead of deltree.pl. In the verbose output in case of failure, I split the difference and added a terminating line "end ls ...", but did not prefix the ls output. While I was testing, that seemed the most usable. Jim, anyone ... look

bug#39078: Path.pm change -> deltree.pl -> t/uninstall-fail failure

Pushed attached patch, closing here. rmrf.diff Description: Binary data

[PATCH] lint: make syntax-check same as maintainer-check.

Next trivial patch: make syntax-check an alias for maintainer-check, since so many other packages recognize syntax-check, as Jim has noted. Wdyt? -k synchk.diff Description: Binary data

bug#32088: Python >=3.5 test suite failures

instmany-python.sh from the somewhat arbitrary 2500 to 3200. Neverthlesss, maybe a more elegant solution is possible. Seems fine to me. Thanks for finding the workaround. 2) The fix/patch of bug #38043 (Incorrect Python byte-compiling for Python 3 and PyPy3), which we also

Re: [PATCH] tests: use skip_ consistently.

how about this instead? (feels a little like removing a double negative): test "$EMACS" = t && EMACS=emacs Indeed, that looks a lot more natural, but as far as I can see, the problem is Automake's pervasive use of set -e. sh-4.2$ test "$FOO" = t && FOO=foo sh-4.2$ echo $? 1 Thus the

Re: byte compilation in older emacs [patch]

2020-01-03 Karl Berry automake: Support byte compilation in older Emacsen * lib/am/lisp.am (am__emacs_byte_compile_setup) [FIRST]: define new make variable, to use byte-compile-dest-file-function if available, else byte-compile-dest-file. (.el.elc): use

byte compilation in older emacs [patch]

Some of the Emacs tests in Automake were failing for me because I was running an older Emacs. Attached is my attempt to support them, without changing the support for newer Emacs. If no objections or comments, I'll push in a day or two. --thanks, karl. byte-compile-old-emacs.diff Description:

[PATCH] tests: Correctly simulate no emacs in t/nobase-nodist.sh

Typo in export command in one test. Barring problems, will push in a day or two. --thanks, karl. am-emcas.diff Description: Binary data

[PATCH] tests: use skip_ consistently.

I belatedly noticed that I should have used skip_ instead of exit 77 in my new too-old-Emacs test. Plus found a wrong occurrence of just "skip" without the _ in uninstall-fail.sh. Look ok? (uninstall-fail has more failures in the case of a newer File::Path, due to changes in rmtree as used in

bug#7860: recursive autoreconf breaks AM_COND_IF conditionalization of AC_CONFIG_FILES

As far as I can tell from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=7860 there is nothing left to do here. Please update if incorrect. Closing via bcc. --karl

bug#22445: [PATCH] test-driver help message is wrong

Hi - back on your report from January 2016 (sorry): The test driver help message indicates that arguments are given using, e.g., "--test-name=NAME", while it only recognizes "--test-name NAME". Belated thanks. I installed your patch, am closing bug. --happy hacking, karl.

bug#32100: [PATCH] automake: Remove duplicate words in aclocal.in

Hi Samy - back on your report from July 2018 (sorry) on a typo in bin/aclocal.in: - # the destination file (rather than a temporary file) is + # destination file (rather than a temporary file) is I've applied this patch and am closing the bug. Thanks! --karl

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

Hi Harald and all - well, Paul or Jim or any other automake worker will know better than me, but my reactions, FWIW: This caused intermittent failures in automake's t/subobj.sh test, which This problem seems like the tip of the iceberg to me. With this change, any dependency which gets

bug#40699: "dist Hook" documentation in manual is incorrect or unclear about write permissions

i.e. it does not change the permissions in order to make the removal work recursively Right, I see it now. Had been testing the wrong thing. So, can you propose a specific change for the manual? -k

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

the command that updates autom4te.cache/traces.0 does not modify configure.ac at the same time. No argument for that specific case. But looking at the change in isolation: - if ($mtime < mtime ($dep)) + if ($mtime <= mtime ($dep)) { verb "up_to_date ($file):

Re: [PATCH] readme: add missing word

-that the range specifies every single year in that closed interval. +note that the range specifies every single year in that closed interval. Thanks for pointing that out. I decided to delete the "that" instead of adding the "note". Pushed. --best wishes, karl.

bug#40699: "dist Hook" documentation in manual is incorrect or unclear about write permissions

Hi Vincent, So, if the subdirectories may not be writable, how can the rm in the first example work without changing the permissions first? [namely:] dist-hook: rm -rf `find $(distdir)/doc -type d -name .svn` That example belongs to the preceding paragraph

bug#10371: Broken links in the on-line automake manual

The attached patch.gz fixes the urls in automake.texi, adds checklinkx to the contrib/ subdirectory, and a new target in doc/local.mk to invoke it for rechecking. Hearing no objection, I pushed this change (last night, belatedly sending this mail, sorry) and am closing this bug. -k

bug#18734: [PATCH] vala: Improper parsing of valac arguments leads to garbage in DIST_COMMON

- if (grep (/$lastflag/, ('-H', '-h', '--header', '--internal-header', - '--vapi', '--internal-vapi', '--gir'))) + if (grep (/^$lastflag$/, ('-H', '-h', '--header', '--internal-header', + '--vapi', '--internal-vapi',

bug#10371: Broken links in the on-line automake manual

Hi Stefano and all -- back on your report about broken urls from 2011 :) -- Date: Mon, 26 Dec 2011 22:03:50 +0100 Feeding the address of the on-line automake manual: to the W3C linkchecker:

bug#18734: [PATCH] vala: Improper parsing of valac arguments leads to garbage in DIST_COMMON

Hi Colomban - back on your automake bug report from six years ago (sorry!): Date: Wed, 15 Oct 2014 17:17:00 +0200 From: Colomban Wendling [...] The problem is that parsing of valac flags uses a non-anchored pattern and so any argument happening to be a subset of a parsed

bug#40699: "dist Hook" documentation in manual is incorrect or unclear about write permissions

+chmod -R u+w $(distdir)/doc ... -echo "Distribution date: `date`" >> README +echo "Distribution date: `date`" >> $(distdir)/README Ok, pushed. Thanks.

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

Hi Ralf, Jose, anyone and everyone, Back on this automake bug report from a mere nine years ago: (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=7994) Date: Sun, 6 Feb 2011 23:20:01 +0100 In a package with a texinfo file, distcheck fails when LaTeX is not installed. Instead, it

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

Probably best to leave it, as is, and mark it as known-to-be-unused at least via comment. How does the text below look for an explanation? (By the way, I noticed that FileUtils.pm, unlike the other *.pm in lib/Automake, doesn't have an =over 4 ... =back around all the other items,

bug#8289: distcheck and make dvi

I've attempted to construct a patch [attached] following my own suggestion :), to create a new variable to allow overriding the "make dvi" which is done as part of distcheck with another target. I named the variable AM_DISTCHECK_DVI_TARGET (if something else seems better, fine). The actual

bug#41101: FAIL: t/tags-lisp-space.sh

Subject: bug#41101: FAIL: t/tags-lisp-space.sh Well, this didn't include the actual error, but I'm guessing you don't have etags installed. I made this fix in the development sources a little while ago, if the failure is troubling you. --thanks, karl. --- a/t/tags-lisp-space.sh +++

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

So fine to remove from automake after all. Good! So removed. Thanks to all. -k

bug#40181: FAIL: t/tags-lisp-space.sh

Hi Andreas, /bin/sh: line 11: etags: command not found I somehow thought presence of etags was already tested for, but obviously not. Anyway, I'll look into it as soon as I can. Thanks for the report. --karl

bug#40192: Please report to bug-automake@gnu.org

FAIL: t/tags-lisp-space.sh ... test-init.sh: etags: not found Thanks for the report. Yeah, have to have etags (or maybe just a link to /bin/true suffices? not sure) for the test to succeed at the moment. Didn't realized that. Will put in a safeguard soon, but any new release is

bug#40181: FAIL: t/tags-lisp-space.sh

I believe all that's needed is to set required=etags in t/tags-lisp-space.sh. Sorry for my dumb mistake. Committed this: --- a/t/tags-lisp-space.sh +++ b/t/tags-lisp-space.sh @@ -18,7 +18,7 @@ # if there are CONFIG_HEADERS. # See automake bug#38139. -required='' +required=etags . test-init.sh

bug#40192: Please report to bug-automake@gnu.org

I believe all that's needed is to set required=etags in t/tags-lisp-space.sh. Sorry for my dumb mistake. Committed this: --- a/t/tags-lisp-space.sh +++ b/t/tags-lisp-space.sh @@ -18,7 +18,7 @@ # if there are CONFIG_HEADERS. # See automake bug#38139. -required='' +required=etags . test-init.sh

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

Lacking further input, I've pushed the following documentation-only change to close this one. A further change, for https://bugs.gnu.org/8289 (which has much more discussion), should make it possible to omit and change running make dvi. --thanks, karl.

bug#16341: vala does not respect -d/--directory to generate dependency rules

Hi - thanks for the report about vala not supporting -d from years ago (sorry). https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16341 I know it's been ages, but in case you're still around ... can you send an example that shows the bug? There are so many details, it's always easier to work from an

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

Hi Akim - regarding the report (from years ago, sorry) that make does not rebuild something in AC_CONFIG_FILES. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16527 Any chance you can send an example? It would not be easy for me to construct this from scratch. --thanks, karl.

bug#14196: Problem with invoking "missing" in directory with "(" in name (Automake 1.11.6, Autoconf 2.68

+ MISSING="\${SHELL} '$am_aux_dir/missing'" ;; I made this change. Two tests (man6 and am-missing-prog) that were grepping for the path to missing needed adjusting for the quotes being present now. Closing this one. Thanks all. -k

bug#14059: broken link in autotools doku (sent to gnu webmasters and autotools developers)

Thanks for the report about the broken link into the automake-history documentary. After a mere seven years :), I've added a .symlinks entry in the automake web repository, so it resolves now. Closing ... --thanks again, karl. P.S. For the record, the same place in the mono automake.html,

bug#14196: Problem with invoking "missing" in directory with "(" in name (Automake 1.11.6, Autoconf 2.68)

Hi - thanks for this bug report (from seven years ago, sorry). 4. now try and configure the project using ./configure or absolutely using sh -c '~/test\(1\)/configure' ... ./configure: eval: line 2084: syntax error near unexpected token `(' ./configure: eval: line 2084:

bug#12142: automake tries to compile a program when 'foo' and 'foo.cxx' exist (though the former is header)

It seems there is nothing left unresolved here, so closing ...

Re: [PATCH] Use ‘use warnings’ instea d of -w on #! lines.

Hi Zack, #!/usr/bin/env perl Glad to hear it (all of it). Thanks much for all the cleanup effort. I installed your patch without change. make check and distcheck also worked for me afterward. I'll send you the usual assignment request separately. Thanks! --karl

bug#14196: Fwd: bug#14196: Problem with invoking "missing" in directory with "(" in name (Automake 1.11.6, Autoconf 2.68

AM_MISSING_HAS_RUN Whoops, sorry for not realizing that. Thanks for fixing my/our bug :). - case $am_aux_dir in - *\ * | *\*) -MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;; - *) -MISSING="\${SHELL} $am_aux_dir/missing" ;; - esac +

Re: [PATCH] maint: Update files from upstream with 'make fetch'

Subject: [PATCH] maint: Update files from upstream with 'make fetch' Sure. Pushed. Thanks.

Re: [PATCH 0/4] Reduce warning category skew between automake and autoconf

Hi Zack - all the changes look fine to me. I added you to the automake group on savannah. Barring anyone else jumping in to the contrary, please go ahead and commit/push. Thanks for all the work. It looks you (re)sent the "use warnings" instead of "-w" patch. I believe I already applied that one,

Re: bug#43683: make install-exec does not trigger make $(BUILT_SOURCES)

Hi madmurphy, install-exec: $(BUILT_SOURCES) $(MAKE) $(AM_MAKEFLAGS) install-exec-am Thanks very much for the bug report, patch, and test case. I just applied and pushed it, with small modifications. Please report back if problems persist. Meanwhile, closing this bug. Thanks

bug#43683: make install-exec does not trigger make $(BUILT_SOURCES)

Hi madmurphy, install-exec: $(BUILT_SOURCES) $(MAKE) $(AM_MAKEFLAGS) install-exec-am Thanks very much for the bug report, patch, and test case. I just applied and pushed it, with small modifications. Please report back if problems persist. Meanwhile, closing this bug. Thanks

bug#44010: Per-compilation C files

Hi Reuben, > Note that currently, you cannot use per-target ø*_VALAFLAGSù (*note > Renamed Objects::) to produce different C files from one Vala source > file. Glad you found that. Unfortunately I have no meaningful clue about Vala. So I can install patches but that's about it.

bug#43819: two FAILs for "make check" -- automake 1.16.2

configure.ac:2: warning: The macro `AC_DIAGNOSE' is obsolete. What version of autoconf? This seems a problematic message. It doesn't happen for me with autoconf 2.69. -k

Re: automake-history texi update 1.16.2

Hi Bob - thanks for the patch. No problem there, but: It assigns the info DIR category to "Information". Have you seen this category used for anything else? It doesn't exist in my dir file, or the dir-example file in Texinfo that I used to maintain, but that's hardly definitive. I wouldn't

bug#42635: uninitialized value in string eq at /usr/bin/automake line 4953.

Use of uninitialized value in string eq at /usr/bin/automake line 4953. Thanks Alexandre. I installed this patch that I hope fixes it. emptyext.patch Description: Binary data

Re: automake-history texi update 1.16.2

Hi Bob, The automake-history.info file has no DIR category assigned. I installed your patch, but using "Software development" for the @dircategory, as we discussed offline. Thanks! --karl

bug#42883: Selecting a subset of tests in recursive make causes unnecessary failures

at a minimum this behavior should be documented with the test subsets documentation and this work around mentioned. Yes, I agree. Contemplating. Ideally, the subset tests feature design should be updated to play nice with makefile recursion. I think I agree again, but ... not

Re: Patch to trigger make $(BUILT_SOURCES) from make install-exec

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43683 Thanks much for the report and patch. Looks sensible. Can you provide a test case (example configure.ac + Makefile.am + tree) that exposes the problem (and thus verifies the patch)? Thanks again, Karl

Re: [RFC PATCH 0/3] Work around autoconf/automake warnings skew (automake side)

location of the new Perl function merge_WARNINGS. I defer to your decision, whichever way you think is better, since it doesn't matter to Automake. Subject: [RFC PATCH 0/3] Work around autoconf/automake warnings skew (automake side) Zack, the Automake changes look fine to me.

bug#9822: AMTAR not used

akim> TAR = tar > am__tar = $(TAR) --format=ustar -chf - "$$tardir" > am__untar = $(TAR) -xf - > would be fine! stefano> I'd prefer to go with this latter option As far as I can tell, all that was left to do here is to document the use of the TAR environment variable in

bug#8289: distcheck and make dvi

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

Back on this bug from 2012, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10852 ak> Also, why two "if"? sl> For the sake of "make -n": * doc/automake.texi (Multiple Outputs): Split commands than reinvoke $(MAKE) to avoid file removals during dry runs. I pushed Akim's patch.

bug#11745: the new test-suite summary is confusing

Hi Alexandre and all - regarding https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11745 (12 years ago, oh well). I upgraded to Automake 1.12.1 to discover the each of these test-suite [directories] now displays a huge summary like:

bug#44129: Patch to improve valac version detection

$ valac --api-version 0.48 Thanks Reuben. Unfortunately, when I install this patch, the t/vala-configure.sh test fails for me with: configure: WARNING: Vala compiler not found or too old configure: WARNING: you will not be able to compile Vala source files I'm using CentOS 7, which

<    1   2   3   4   5   6   7   8   >