1.16j: test release incoming

or this whole subsecond-mtime problem. With this set to "sleep 1", Do not use "sleep x" in the above tests. Use "$sleep" instead. make: *** [maintainer/syntax-checks.mk:443: sc_tests_plain_sleep] Error 1 So I adjusted via the second attached change. Now, I think it will succe

[bug#59991] [PATCH v2 0/3] Port tests to modern C

On Thu, Dec 15, 2022 at 10:19 PM Frederic Berat wrote: > From: Frédéric Bérat > Hello, > > There is ongoing work from both GCC and Clang community to set the C99 > standard > as the default one. > In this context, Fedora packages were rebuilt with some warnings turned as > errors to simulate

[bug#60807] [PATCH v2] tests: reuse am_cv_filesystem_timestamp_resolution

On Sat, Jan 14, 2023 at 4:19 PM Mike Frysinger wrote: > Rather than assume such coarse delays, re-use existing logic for > probing the current filesystem resolution. This speeds up the > testsuite significantly. On my system, it speeds -j1 up quite a > lot -- by ~30%. While I didn't gather

bug#60807: [PATCH 1/2] mtime: use Time::HiRes::stat when available for subsecond resolution

On Sun, Jan 15, 2023 at 12:27 AM Mike Frysinger wrote: > On 14 Jan 2023 21:27, Jacob Bachmeyer wrote: > > Mike Frysinger wrote: > > > --- a/lib/Automake/FileUtils.pm > > > +++ b/lib/Automake/FileUtils.pm > > > @@ -42,6 +42,11 @@ use Exporter; > > > use File::stat; > > > use IO::File; > > > > >

Re: make check(s) pre-release problems

On Thu, Oct 6, 2022 at 1:28 PM Karl Berry wrote: > > No errors on RHEL7+autoconf2.71 > > Puzzling. Can you easily try RHEL8 or one of its derivatives? > It surprises me that that is the culprit, but it seems possible. > > I'm using autoconf-2.71, make-4.3, etc., compiled from source, but am >

fix: autoreconf fails due to .m4 files added but not installed

GS_N I've just pushed the attached fix. Introduced in v1.16.5-46-g38da1d906 and v1.16.5-45-g3099097d7 so this doesn't need a NEWS update. Mike, can you add an automake test that would have caught this? >From 208f103f2607eaed95aa0d227c5627b4363ffb7b Mon Sep 17 00:00:00 2001 From: Jim Meyering Date

Re: How to speed up 'automake'

On Mon, May 23, 2022 at 1:48 PM Karl Berry wrote: > > I was going to bisect but if it doesn't fail for me in the first place... > :( > > Thanks. Indeed, reconfiguring etc. got rid of those errors. > > Now a bunch (12) of the Python tests are failing for me, presumably > because of previous

Re: How to speed up 'automake'

On Tue, May 3, 2022 at 2:57 PM Karl Berry wrote: > > I see no reason why mv would be so crucial. > > Hmm, I guess you're right. Thanks for the analysis. > > The purpose of the stamp files is to avoid partial files being written > (and screwing up future makes), but if the file is zero bytes,

Re: How to speed up 'automake'

On Tue, May 3, 2022 at 3:55 PM Nick Bowler wrote: > > On 2022-05-02, Karl Berry wrote: > > - @echo '# dummy' >$@-t && $(am__mv) $@-t $@ > > + @: >>$@ > > > > 1) does it actually speed anything up? > > The answer seems to be a resounding "yes". I tried one of my packages > on an old slow

Re: Need better release validation documentation/strategy.

On Fri, Apr 8, 2022 at 6:30 AM Bob Friesenhahn wrote: > Today I saw an announcement for a new version of gzip. It provided > lots of data for how to verify the downloaded tarballs. I recently > saw a very similar announcement for a new version of libtool. I am not > sure where the template of

[bug#53951] [PATCH] m4: speed up filesystem modification checks

On Sat, Feb 12, 2022 at 2:07 AM Mike Frysinger wrote: > The current code sleeps at least 1 second to make sure the generated > files are strictly newer than the source files. It does this for a > few reasons: POSIX only guarantees that `sleep` accept integers, and > filesystems have a history

Re: minor docs alteration

On Tue, Jan 18, 2022 at 10:01 AM Mike Frysinger wrote: > On 31 May 2018 22:44, Jefferson Carpenter wrote: > > Subject: [PATCH] automake.texi: clarify relationship between configure and > > build dir > > > > I know you what this meant, but as a kid this would have confused me - the > > word "in"

Re: [PATCH] Use gender-neutral pronouns in HACKING and t/README

On Tue, Jan 18, 2022 at 10:03 AM Mike Frysinger wrote: > On 08 Apr 2018 16:07, Matthew Leeds wrote: > > --- > > HACKING | 4 ++-- > > t/README | 2 +- > > thanks for the patch. looks like Jim fixed HACKING: >

Re: [PATCH] tests: fix py-compile-basedir.sh: add missing test call

On Tue, Jan 18, 2022 at 10:29 AM Mike Frysinger wrote: > On 18 Jan 2022 09:48, Jim Meyering wrote: ... > > But IMHO that's too much duplication/syntax. > > How about this instead? > > > > case $(echo "$files" | wc -l) in 4|6) ;; *) false;; esac > > l

Re: [PATCH] tests: fix py-compile-basedir.sh: add missing test call

On Tue, Jan 18, 2022 at 7:46 AM Mike Frysinger wrote: > From: Thomas Deutschmann > > Commit b279a0d46dfeca1ca40057c3c910ab1657d60be5 ("tests: in python > tests, do not require .pyo files (for python3)") had a slight logic > error in that it missed a `test` call. > > Reported to Gentoo at

Re: multiple online manual versions

On Tue, Jan 18, 2022 at 8:14 AM Mike Frysinger wrote: > currently the automake website only hosts one manual version -- the latest. > when working with older code bases, especially when trying to update them > to newer versions, it can be helpful to have the older manual available to > quickly

FYI, updated copyrights

FYI, I've just updated copyright messages for the new year: https://git.savannah.gnu.org/cgit/automake.git/commit/?id=6c8ff6a8f3c80f86e703a3fc2a0ffb81e87f0957

bug#21336: [PATCH] configure: handle KCC on case-insensitive filesystems

On Thu, Dec 9, 2021 at 10:56 PM Mike Frysinger wrote: > This fixes https://debbugs.gnu.org/21336. On macOS 10.10, there seems Note that I still see kcc on 12.0.1 > to be a kerberos tool installed as "kcc" which breaks the check. > > Also resync with latest autoconf which searches for clang++

Re: [PATCH] configure: handle KCC on case-insensitive filesystems

On Thu, Dec 9, 2021 at 10:56 PM Mike Frysinger wrote: > This fixes https://debbugs.gnu.org/21336. On macOS 10.10, there seems Note that I still see kcc on 12.0.1 > to be a kerberos tool installed as "kcc" which breaks the check. > > Also resync with latest autoconf which searches for clang++

Re: [PATCH] m4: replace AC_DIAGNOSE with m4_warn

On Sat, Dec 11, 2021 at 10:07 PM Mike Frysinger wrote: > AC_DIAGNOSE was marked obsolete with autoconf-2.62 in 2008. > > * m4/obsolete.m4: Change AC_DIAGNOSE to m4_warn. > --- > m4/obsolete.m4 | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/m4/obsolete.m4

Re: [PATCH 1/2] m4: warn when AM_SILENT_RULES default is used

On Sat, Dec 11, 2021 at 10:09 PM Mike Frysinger wrote: > To help ease people into enabling silent rules by default, warn if > a package doesn't make an explicit selection. > --- > NEWS | 10 ++ > m4/silent.m4 | 6 +- > 2 files changed, 15 insertions(+), 1 deletion(-) > >

Re: [RFC/PATCH] m4: enable silent build rules by default

On Sun, Dec 12, 2021 at 7:14 AM Zack Weinberg wrote: > > On Sun, Dec 12, 2021, at 1:10 AM, Mike Frysinger wrote: > > On 07 Dec 2021 21:58, Zack Weinberg wrote: > >> On Tue, Dec 7, 2021, at 9:49 PM, Mike Frysinger wrote: > >> > This has been available since automake 1.11 released over a decade >

Re: [platform-testers] automake-1.16g snapshot

On Mon, Sep 20, 2021 at 12:03 AM Dagobert Michelsen wrote: > Hi Jim, > > Am 20.09.2021 um 04:37 schrieb Jim Meyering : > > We're preparing for a new release. > > See NEWS below. Please give it a spin and report any success or failure. > > > > Thanks to K

automake-1.16g snapshot

contributed! The following people contributed changes to this release: Akim Demaille (1) Dimitri Papadopoulos (1) Jan Engelhardt (1) Jim Meyering (2) Karl Berry (5) Nick Bowler (1) Jim [on behalf of the automake maintainers

Re: automake-1.16d snapshot

On Sun, Jul 18, 2021 at 8:06 PM Jim Meyering wrote: > We're preparing for a new release, so here's the latest. > Please give it a spin and report any success or failure. > I'd like to release 1.16.4 within a week or so. > > Thanks to Karl yet again for doing so much of the work.

automake-1.16d snapshot

the NEWS below for a brief summary. Thanks to everyone who has contributed! The following people contributed changes to this release: Allison Karlitskaya (2) Dirk Mueller (1) Jacob Bachmeyer (1) Jim Meyering (7) Joshua Root (1) Karl Berry (25) Mike Frysinger (1) Nick Gasson (1

Re: [PATCH v1] Fix misuse of DejaGnu in Automake testsuite

On Tue, Jul 13, 2021 at 9:39 PM Jacob Bachmeyer wrote: > This is a revised patch that changes the DejaGnu tests in the Automake > testsuite to properly use a testsuite/ directory. A previous "v0" of > this patch was sent to the general Automake list as an illustration of > the problem, but that

Re: Automake testsuite misuses DejaGnu

On Sun, Jul 11, 2021 at 9:03 PM Jacob Bachmeyer wrote: > I was planning to find a solution with a complete patch before > mentioning this, but since a release is imminent I will just state the > problem: several tests in the Automake testsuite misuse DejaGnu and > fail with the 1.6.3 DejaGnu

snapshot imminent

Karl and I have just pushed a few changes (thanks, Karl and Allison!). With those, I think we're ready for a release. I will make the usual pre-release snapshot, probably tomorrow.

Re: [PATCH] dist: add new "pure-dist" automake option

On Mon, Jul 5, 2021 at 4:16 PM Jim Meyering wrote: > In incidentally-related news, I found that make check now hangs on > tests-environment-fd-redirect on Fedora 34, so I'm investigating that. FYI, I'm currently working around this by disabling the ksh-testing part of that test: fedo

Re: [PATCH] dist: add new "pure-dist" automake option

On Sun, Jul 4, 2021 at 2:19 PM Karl Berry wrote: > > - I used the word "pure" in the sense of a pure function, > > Yes, I realized. > > My thought was that, suppose some other similar change is needed in the > future that changes what gets automatically distributed, or > prerequisites, or

Re: Add support for README.md as optional alternative to README

On Mon, May 31, 2021 at 4:53 PM Karl Berry wrote: > Markdown is a great invention and I believe time has come for GNU packages > to support README.md files as optional alternatives to plain READMEs. > > Seems fine to me. (Jim?) Thanks. -k The patch is fine. Thanks indeed.

automake-1.16.3 released [stable]

. Thanks to everyone who has contributed! The following people contributed changes to this release: Akim Demaille (1) Colomban Wendling (1) Felix Yan (1) Issam E. Maghni (1) Jim Meyering (12) Karl Berry (23) Miro Hron\v{c}ok (1) Paul Eggert (4) Reuben Thomas (3) Robert Menteer (1

Re: preparing for a new release

On Sun, Nov 15, 2020 at 6:52 PM Karl Berry wrote: > > Hi Jim - (and thanks for the test runs and logs, Gavin) > > make -k check TESTS='t/txinfo-no-clutter' \ > AM_TESTSUITE_MAKE="make -j$(( 2*$(nproc) + 1 ))" > > I know little about programming for parallel (auto)make,

preparing for a new release

Karl has made quite a few improvements, so I'm preparing to make a new release. But first, I wanted to make the tests pass reliably also when running them in parallel (the only way I run them, because otherwise, they take way too long). I run a command like this: make check

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

On Fri, Sep 4, 2020 at 4:38 PM Zack Weinberg wrote: > OK, after a quick investigation, the failure happens at configure time > but the problem code belongs to automake. Specifically, > AM_MISSING_HAS_RUN. I think the tidiest fix is to quote the value of > $am_aux_dir/missing unconditionally: > >

Re: problems with "make install" directory permissions

On Mon, Jul 27, 2020 at 3:03 PM Paul Eggert wrote: > > On 7/27/20 2:24 PM, Karl Berry wrote: > > https://lists.gnu.org/r/bug-bison/2020-07/msg00042.html > > > > I can understand increasing permissions to allow +rx on installation > > directories, but why force 755, thus disallowing group

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

On Mon, Jun 1, 2020 at 6:46 PM Karl Berry wrote: > 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#8289: distcheck and make dvi

On Sun, May 17, 2020 at 9:44 AM Karl Berry wrote: > 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

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

On Sat, May 9, 2020 at 8:05 PM Harald van Dijk wrote: > On 10/05/2020 02:10, Karl Berry wrote: > > +Although we would like to remove this function from Automake, since it's > > +not used, that would break older versions of Autoconf, which seems > > +gratuitious. So we leave it, unchanged. > >

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

On Sat, May 9, 2020 at 6:10 PM Karl Berry wrote: > > 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? Very good! Thanks for dealing with this. Two suggestions below. > (By the way, I noticed

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

On Mon, Apr 20, 2020 at 6:13 PM Karl Berry wrote: > 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

automake-1.16.2 released [stable]

the NEWS below for a brief summary. Thanks to everyone who has contributed! The following people contributed changes to this release: Bruno Haible (1) Gavin Smith (1) Giuseppe Scrivano (1) Jim Meyering (5) Karl Berry (12) Libor Bukata (1) Lukas Fleischer (2) Mathieu Lirzin (8) Paul

Re: dependency tracking error message

On Thu, Feb 13, 2020 at 6:40 PM Karl Berry wrote: > Looking at the automake-patches that have accumulated, I saw one to > improve the error message if dependency tracking fails. Copied below. > > It seems generally sensible to me, though I would change the wording a > little, and there is a

Re: t/aclocal-print-acdir.sh at installcheck and AUTOMAKE_UNINSTALLED

On Mon, Feb 3, 2020 at 6:23 PM Karl Berry wrote: > The aclocal-print-acdir.sh test fails at the make installcheck step of > make distcheck (it succeeds in the normal make check, and it succeeds at > the make check of make distcheck; only fails in the make installcheck). > > This is because

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

On Sun, Jan 19, 2020 at 6:25 PM Karl Berry wrote: > 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 Perfect. Thanks!

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

On Sat, Jan 18, 2020 at 6:11 PM Karl Berry wrote: > 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

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

On Sun, Jan 12, 2020 at 6:41 PM Karl Berry wrote: > > 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

Re: [PATCH] tests: use skip_ consistently.

On Wed, Jan 8, 2020 at 2:03 PM Karl Berry wrote: > > 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. > >

Re: [PATCH] tests: use skip_ consistently.

On Tue, Jan 7, 2020 at 6:25 PM Karl Berry wrote: > 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? Good catches both. I noticed this added line:

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

On Sun, Jan 5, 2020 at 6:22 PM Karl Berry wrote: > Typo in export command in one test. Barring problems, will push in a day > or two. --thanks, karl. Good catch. Thanks. That was introduced back in a 2011 commit, v1.11-449-g0b7d3cbc9

Re: byte compilation in older emacs [patch]

On Fri, Jan 3, 2020 at 6:13 PM Karl Berry wrote: > > Sigh. I failed to note that vc-dwim did not dwim; my summary first line > was once again not recognized. (And I guess I should update the date.) > I'll figure that out before pushing, but anyway, the content of the > patch is what really needs

FYI: fixing "maintainer-check" tests

I've just fixed some FP nits: [PATCH] maint: make maintainer-check tests pass * maintainer/syntax-checks.mk (sc_sanity_gnu_grep): Remove NUL byte from grep output, to avoid shell diagnostic about "NUL byte suppressed from expansion." (automake_diff_no, aclocal_diff_no): Adjust number of expected

Re: t/txinfo-vtexi4.sh and timezone failure

On Fri, Dec 20, 2019 at 6:15 PM Karl Berry wrote: > > The automake test t/txinfo-vtexi4.sh failed when localtime and UTC were > on different days, resulting in the GREPDATE for the @UPDATED@ string > not matching (among possible others). > > mdate-sh always uses TZ=UTC0. This tiny change makes

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

On Mon, Nov 11, 2019 at 6:55 PM Luca Saiu wrote: > > On 2019-11-10 at 14:24 +0100, Luca Saiu wrote: > > > using lisp_DATA rather than lisp_LISP prevents the misbehavior. > > But, incidentally, using lisp_DATA also prevents tag generation from the > Emacs Lisp sources. Thanks to both of you. Karl

Re: [PATCH] dist: add dist-zstd option

On Sat, Nov 16, 2019 at 12:23 PM Giuseppe Scrivano wrote: > Jim Meyering writes: > > On Mon, Nov 11, 2019 at 12:35 PM Giuseppe Scrivano > > wrote: > >> Hi Jim, > >> > >> Jim Meyering writes: > >> > >> > On Fri, Oct 4, 2019 a

Re: [PATCH] dist: add dist-zstd option

On Mon, Nov 11, 2019 at 12:35 PM Giuseppe Scrivano wrote: > Hi Jim, > > Jim Meyering writes: > > > On Fri, Oct 4, 2019 at 8:03 AM Giuseppe Scrivano > > wrote: > >> add support for using the zstd compression algorithm. > > > > Hi Giuseppe, &g

Re: [PATCH] dist: add dist-zstd option

On Fri, Oct 4, 2019 at 8:03 AM Giuseppe Scrivano wrote: > add support for using the zstd compression algorithm. Hi Giuseppe, Thank you for that patch. I've adjusted it and propose the attached, which makes these changes: - add tests - that exposed the need for a correction, s/-d/-dc/ in

Re: bug#34201: [PATCH] automake: do not require @setfilename in Texinfo files

On Sat, Sep 14, 2019 at 5:35 AM Gavin Smith wrote: > On Mon, Sep 2, 2019 at 6:28 PM Jim Meyering wrote: > > > > Gavin Smith proposed a patch for this back in http://bugs.gnu.org/34201 > > Another reference to the problem: http://bugs.gnu.org/36921 > > > > In the

bug#34201: [PATCH] automake: do not require @setfilename in Texinfo files

On Sat, Sep 14, 2019 at 5:35 AM Gavin Smith wrote: > On Mon, Sep 2, 2019 at 6:28 PM Jim Meyering wrote: > > > > Gavin Smith proposed a patch for this back in http://bugs.gnu.org/34201 > > Another reference to the problem: http://bugs.gnu.org/36921 > > > > In the

[PATCH] automake: do not require @setfilename in Texinfo files

Gavin Smith proposed a patch for this back in http://bugs.gnu.org/34201 Another reference to the problem: http://bugs.gnu.org/36921 In the attached (in Gavin's name), I've added a NEWS entry and adjusted the ChangeLog entry. Will push in a day or so if no comment.

bug#36921: [PATCH] automake: do not require @setfilename in Texinfo files

Gavin Smith proposed a patch for this back in http://bugs.gnu.org/34201 Another reference to the problem: http://bugs.gnu.org/36921 In the attached (in Gavin's name), I've added a NEWS entry and adjusted the ChangeLog entry. Will push in a day or so if no comment.

Re: [PATCH] ar-lib: Fix for MSVC 14.

On Wed, Jul 3, 2019 at 6:52 PM Bruno Haible wrote: > Hi, > > When building GNU gettext HEAD (0.20.1+) with MSVC 14, the creation of > libtextstyle.la fails, because it can't extract the members of several > sub-libraries (*.lib files). The reason is that the > lib -NOLOGO -LIST some.lib > lists

Re: __pycache__ directories and distcleancheck

Thanks for the report. Would you please create a minimal set-up to demonstrate the problem? That will probably expedite a proper fix. On Wed, Jun 13, 2018, 11:56 Adam Mercer wrote: > Hi > > We've recently updated our code to support Python3 and are running > into a problem with __pycache__

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Mon, Dec 11, 2017 at 11:03 AM, Jim Meyering <j...@meyering.net> wrote: > On Mon, Dec 11, 2017 at 9:56 AM, Glenn Morris <r...@gnu.org> wrote: >> >> Jim Meyering wrote (on Sun, 10 Dec 2017 at 17:01 -0800): >> >>> However, I don't see how "-f batch-b

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Mon, Dec 11, 2017 at 9:56 AM, Glenn Morris <r...@gnu.org> wrote: > > Jim Meyering wrote (on Sun, 10 Dec 2017 at 17:01 -0800): > >> However, I don't see how "-f batch-byte-compile" can be used when >> the .elc file must be created in a directory separate fr

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Wed, Nov 29, 2017 at 12:17 PM, Glenn Morris wrote: > The obsolete bytecomp feature is back as of Emacs 9964db4. Thanks, I noticed when that was restored, but have been a way for a while. > BTW, why doesn't lisp.am use the standard "-f batch-byte-compile" > method of producing

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

On Tue, Nov 28, 2017 at 8:35 PM, Nick Bowler <nbow...@draconx.ca> wrote: > On 2017-11-28 18:13 -0800, Jim Meyering wrote: >> On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler <nbow...@draconx.ca> wrote: >> > The Automake manual unequivocally states that BUILT_SOURCES file

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

On Tue, Nov 28, 2017 at 12:01 PM, Mathieu Lirzin wrote: > Hello Jim, ... >> >> Here's the patch I expect to push to master: ... > > OK to push. Thanks. Pushed. I have also removed the micro branch.

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Tue, Nov 28, 2017 at 2:23 PM, Glenn Morris <r...@gnu.org> wrote: > Jim Meyering wrote: > >> Remember: this arises only in a non-srcdir build. That means build >> artifacts end up being written into the mostly-empty current directory >> hierarchy, which does

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler <nbow...@draconx.ca> wrote: > Hi Jim, > > On 2017-11-28 11:21 -0800, Jim Meyering wrote: >> Date: Thu, 20 Mar 2014 12:31:32 -0700 >> Subject: [PATCH] "make dist" did not depend on $(BUILT_SOURCES) >&g

[PATCH] "make dist" did not depend on $(BUILT_SOURCES)

is: src/hello.c:27:10: fatal error: configmake.h: No such file or directory #include "configmake.h" ^~ Here's the patch I expect to push to master: From: Jim Meyering <meyer...@fb.com> Date: Thu, 20 Mar 2014 12:31:32 -0700 Subject: [PATCH] "make dist&

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Mon, Nov 27, 2017 at 8:12 PM, Jim Meyering <j...@meyering.net> wrote: > On Mon, Nov 27, 2017 at 12:52 PM, Jim Meyering <j...@meyering.net> wrote: >> On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris <rgm+n...@gnu.org> wrote: >>> Jim Meyering wrote: >&g

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Mon, Nov 27, 2017 at 12:52 PM, Jim Meyering <j...@meyering.net> wrote: > On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris <rgm+n...@gnu.org> wrote: >> Jim Meyering wrote: >> >>> In May of 2017, support for using the long-deprecated >>> byte-compile-des

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris <rgm+n...@gnu.org> wrote: > Jim Meyering wrote: > >> In May of 2017, support for using the long-deprecated >> byte-compile-dest-file function was removed, and that removal broke >> automake's elisp-compiling rule for a

Re: Update HACKING (was: [PATCH] port elisp-compilation support to emacs-23.1 and newer)

On Fri, Nov 24, 2017 at 4:42 AM, Mathieu Lirzin wrote: > Mathieu Lirzin writes: > >> Indeed HACKING is not up-to-date, I will fix that. > > Here is a patch that should help describing the new branching model more > accurately. If you see further improvements or would

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Thu, Nov 23, 2017 at 3:57 PM, Mathieu Lirzin <m...@gnu.org> wrote: > Hello Jim, > > Jim Meyering <j...@meyering.net> writes: > >> On Thu, Nov 23, 2017 at 7:38 AM, Jim Meyering <j...@meyering.net> wrote: >>> I wanted to make a new idutils release, bu

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

On Thu, Nov 23, 2017 at 7:38 AM, Jim Meyering <j...@meyering.net> wrote: > I wanted to make a new idutils release, but was blocked because > its "make distcheck" would fail. That was because it distributes > and builds from an elisp file, and automake's elisp-compilati

[PATCH] port elisp-compilation support to emacs-23.1 and newer

ttps://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00551.html >From ecad5844100d5193ecd58f66f31f6bbf0ef04e23 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyer...@fb.com> Date: Wed, 22 Nov 2017 21:07:29 -0800 Subject: [PATCH] port elisp-compilation support to emacs-23.1 and newer In M

Re: [PATCH v3] new option: object-shortname

On Mon, Aug 29, 2016 at 11:05 PM, Thomas Martitz wrote: > This option is intended to be used in conjunction with subdir-objects and > Automake-time substitutions for included makefile fragments (%C%, %D%). > Enabling the option shortens the file name of object files such that

FYI: update copyright dates for 2017

FYI, I've just pushed a commit to update copyright dates: maint: update copyright dates for 2017 * all files: Run this command, using update-copyright from gnulib: UPDATE_COPYRIGHT_FORCE=1 \ UPDATE_COPYRIGHT_USE_INTERVALS=2 \ UPDATE_COPYRIGHT_MAX_LINE_LENGTH=79 \

Re: bug#22702: [bug-grep] grep-2.23 build feedback

On Thu, Sep 8, 2016 at 7:20 PM, Paul Eggert <egg...@cs.ucla.edu> wrote: > Jim Meyering wrote: >> >> I actually wrote a patch to fix the automake bug that led to this, >> but did not find the time to write a stand-alone test case. >> Today, I wrote the

bug#23661: [PATCH] compile: remove .Tpo file upon failure

On Mon, May 30, 2016 at 9:08 PM, Jim Meyering <j...@meyering.net> wrote: > I was annoyed not to be able to use automake's latest-from-master > while preparing for a diffutils release: "make distcheck" would fail > with a single left-over .Tpo file under gnulib-tes

bug#23661: [PATCH] compile: remove .Tpo file upon failure

r in a day or two. From c6dff7e2cac2e8dc5407c77998ef0ac2ba538891 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyer...@fb.com> Date: Mon, 30 May 2016 17:07:52 -0700 Subject: [PATCH] compile: remove .Tpo file upon failure When generating a .deps/base.Po file, we first write to a temporary .Tpo fi

bug#23491: [Automake] Proposed upgrade of the home page

On Mon, May 9, 2016 at 1:34 AM, Thérèse Godefroy wrote: > Hello, > > I am a member of the gnu.org French translation team [0], and also try > to update obsolete features in web pages to make future style > improvement easier. automake.html [1] has the old kind of translation >

Re: bug#22702: [bug-grep] grep-2.23 build feedback

attaching the incomplete diff (no NEWS and no test) here, in case someone wants to help move this along before I find time. From 7a5fb319e557a94b64785d4312ceda197e317248 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyer...@fb.com> Date: Thu, 18 Feb 2016 09:19:44 -0800 Subject: [PATCH] do no

[PATCH] tests: depcomp2: avoid spurious failure on OS/X

I expect to push this trivial patch to master by Monday. Holler if you'd rather it go elsewhere. From 5ac6a241b117f372808b9d2a6ac78ca9af42dfaf Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@fb.com Date: Thu, 20 Mar 2014 13:44:48 -0700 Subject: [PATCH] tests: depcomp2: avoid spurious failure

Re: reinstate AM_PROG_MKDIR_P

Stefano Lattarini wrote: On 10/25/2012 07:32 PM, Jim Meyering wrote: You wrote: OK, if someone sends a patch reverting the AM_PROG_MKDIR_P removal (with a rationale in the commit message), I'll take it. But AM_PROG_MKDIR_P will be dropped in 1.14, without further ifs or buts. Hi Stefano

reinstate AM_PROG_MKDIR_P

still passes. I have spent too little time investigating the merge conflicts, so odds are good that you'll find more than nits to pick. From 0593ddfd6f6a2ed58aaa1aa7e0b361d4a5108924 Mon Sep 17 00:00:00 2001 From: Jim Meyering j...@meyering.net Date: Mon, 22 Oct 2012 16:14:49 +0200 Subject: [PATCH

[PATCH] maint: typo fixes s/lies into/lies in/

Pushed to maint as obvious/trivial: From dcff988359f0dba5d133bbacde8fcb983108ccbf Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Sun, 23 Sep 2012 18:22:30 +0200 Subject: [PATCH] maint: typo fixes s/lies into/lies in/ --- automake.in | 10 +- 1 file changed, 5

Re: AM_PROG_MKDIR_P: too soon to obsolete this macro?

Stefano Lattarini wrote: On 09/12/2012 09:20 PM, Jim Meyering wrote: Stefano Lattarini wrote: On 09/12/2012 06:04 PM, Jim Meyering wrote: I see that gettext (latest from git) still AC_REQUIRE's AM_PROG_MKDIR_P from its intl.m4 and po.m4 files, which are pulled into *many* projects. I know

[PATCH] fix typo in mk-dirp.m4: s/AM_MKDIR_P/AM_PROG_MKDIR_P/

* t/gettext-macros.sh: Fix typo in name of macro emitted into mk-dirp.m4: s/AM_MKDIR_P/AM_PROG_MKDIR_P/ --- t/gettext-macros.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/gettext-macros.sh b/t/gettext-macros.sh index 1d94dad..f548d1a 100755 --- a/t/gettext-macros.sh

Re: [PATCH] fix typo in mk-dirp.m4: s/AM_MKDIR_P/AM_PROG_MKDIR_P/

Stefano Lattarini wrote: Hi Jim, thanks for the patch. On 09/12/2012 05:53 PM, Jim Meyering wrote: * t/gettext-macros.sh: Fix typo in name of macro emitted into mk-dirp.m4: s/AM_MKDIR_P/AM_PROG_MKDIR_P/ Yikes, how have I been missing that ?!? Maybe, to help me (and future readers

Re: [PATCH] fix typo in mk-dirp.m4: s/AM_MKDIR_P/AM_PROG_MKDIR_P/

Stefano Lattarini wrote: On 09/12/2012 09:38 PM, Jim Meyering wrote: I presume you'd like this to be committed on maint? OK thanks, with just one nit ... Pushed to master. The offending code is not on maint. From 335cea6d5e62d011f9fe1f470d336d85599a5ef5 Mon Sep 17 00:00:00 2001 From: Jim

libvirt build failure w/GNU make and automake.git (automake regression?)

When I run ./autogen.sh make, I see this: (this arose because I had the latest automake.git/master tools -- commit c1b83e1af60b866cf5cdeebf77d0275019bad8b2 from today -- early in my path) Generated 3 wrapper functions CC libvirtmod_la-libvirt-override.lo CC

AM_PROG_MKDIR_P: too soon to obsolete this macro?

I see that gettext (latest from git) still AC_REQUIRE's AM_PROG_MKDIR_P from its intl.m4 and po.m4 files, which are pulled into *many* projects. When I try to build one of those projects (coreutils) using the latest from automake.git/master, I see this failure: $ aclocal -I m4

Re: AM_PROG_MKDIR_P: too soon to obsolete this macro?

Stefano Lattarini wrote: On 09/12/2012 06:04 PM, Jim Meyering wrote: I see that gettext (latest from git) still AC_REQUIRE's AM_PROG_MKDIR_P from its intl.m4 and po.m4 files, which are pulled into *many* projects. I know. I sent a patch several months ago to gettext to fix that issue

latest automake makes emacs bootstrap fail

Just a heads up: In the very latest automake (from git), $MISSING is now invoked with the --is-lightweight option. That new usage causes emacs' bootstrap (also from git) to fail because its missing script does not yet know about the --is-lightweight option. In my case, I've simply copied

bug#12320: bison 2.6.2 contains stale info files

Akim Demaille wrote: ... So, Karl, Jim, and others, would you accept that gendocs.sh stopped generating a compressed tarball of split info files, but would rather ship a compressed --no-split file? Sounds fine to me, but gendocs.sh is Karl's baby ;-)

Re: parallel make check output lines are lost!?!

Stefano Lattarini wrote: Hi Jim. On 08/01/2012 04:52 PM, Jim Meyering wrote: I ran coreutils make check tests 60 times (on Fedora 17, x86_64), recording the results of each run like this: for i in $(seq 100); do make -j25 check So, parallel make ... -C tests VERBOSE=yes

  1   2   3   >