Re: REPLACE_GNU_GETOPT

Tom Tromey [EMAIL PROTECTED] writes: | "Hal" == Duston, Hal [EMAIL PROTECTED] writes: | | Hal I am setting my package up with automake/autoconf, and want to | Hal provide gnu getopt if it is not available. I noticed | Hal AC_REPLACE_GNU_GETOPT in the info file, but it doesn't seem to be | Hal

test pr19 failure: explanation

/ChangeLog,v retrieving revision 1.287 diff -u -p -r1.287 ChangeLog --- ChangeLog 2000/02/02 04:29:02 1.287 +++ ChangeLog 2000/03/04 11:34:19 @@ -1,3 +1,8 @@ +2000-03-04 Jim Meyering [EMAIL PROTECTED] + + * pr19.test (DISTCLEANFILES): Define so that these files are removed

Re: Autoconf regex test

the test | program file? Sounds like this macro will do what you want -- to see it in action, look in m4/ in ftp://alpha.gnu.org/gnu/fetish/sh-utils-2.0g.tar.gz #serial 7 dnl Initially derived from code in GNU grep. dnl Mostly written by Jim Meyering. dnl Usage: jm_INCLUDED_REGEX([lib/regex.c

Re: patch: AC_CONFIG_HEADERS

Akim Demaille [EMAIL PROTECTED] writes: | This simple patch just changes | | - if (/A([CM])_CONFIG_HEADER\s*\((.*)\)/ | + if (/A([CM])_CONFIG_HEADERS?\s*\((.*)\)/ | | but there are some trailing spaces which were killed too by | whitespace.el. Applied. Thanks.

Re: [Harlan Stenn Harlan.Stenn@pfcs.com] Re: obsolete AC_OUTPUT_COMMANDS in AM_CONFIG_HEADER

Akim Demaille [EMAIL PROTECTED] writes: | This patch is still lacking in the current Automake. | | Akim Thanks. I'll commit this instead: --- automake.in.~3~ Sat Apr 15 10:29:27 2000 +++ automake.in Sat Apr 15 12:52:42 2000 @@ -4402,8 +4402,8 @@ sub scan_one_configure_file

Re: [Harlan Stenn Harlan.Stenn@pfcs.com] Re: obsolete AC_OUTPUT_COMMANDS in AM_CONFIG_HEADER

I've just checked it in. Sorry about the delay. * automake.in (scan_one_configure_file): Handle the AC_CONFIG_FILES macro. Based on a patch from Harlan Stenn. Akim Demaille [EMAIL PROTECTED] writes: | In response to Didier in another thread, I don't think this patch was |

Re: Patch: init.m4

Hi! Akim Demaille [EMAIL PROTECTED] writes: ... | | +[AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE", [Name of package.]) | | +AC_DEFINE_UNQUOTED(VERSION, "$VERSION", [Version number of package.])]) | | Hm, is it because you differentiate sentences from labels? It is true | that most other entries

Re: Patch: init.m4

Akim Demaille [EMAIL PROTECTED] writes: | Maybe this patch could be rejected/discussed/applied? I've applied it. But removed the periods you added here: +[AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE", [Name of package.]) +AC_DEFINE_UNQUOTED(VERSION, "$VERSION", [Version number of package.])])

Re: [patch]: recognize AC_LIBOBJ

Tom Tromey [EMAIL PROTECTED] writes: | Jim I'll check it in tomorrow unless I hear an objection. | | Jim * automake.in (scan_one_configure_file): Recognize AC_LIBOBJ. | | Please do. Thanks Jim. | In general patches that help automake interoperate with the current | autoconf don't require any

m4/header.m4 has several problems (patch)

I've just made the latest CVS versions of automake and autoconf work together to generate configure et. al. for the fileutils. Here's one of the changes I had to make: (I'm still trying to find a good fix for a depcomp-related problem) * m4/header.m4 (AM_CONFIG_HEADER): Fix typo in

Re: subdir4.test

:-) but that wasn't one of them. | | 2000-08-06 Jim Meyering [EMAIL PROTECTED] | | | | * Makefile.am (TESTS): Add subdir4.test. | | * subdir4.test: New test for the just-fixed depcomp failure. | | [...] | | | | 2000-03-19 Tom Tromey [EMAIL PROTECTED] | | | | * libobj2.test

thanks! [Re: 01-factor-all.patch

Akim Demaille [EMAIL PROTECTED] wrote: ... | Akim I meant, `Makefile' must be done before `all', but not | Akim `$(DATA)', which is now a dependency of all-am, not `all'. | Akim There was no such distinction before, but for `config.h' (one | Akim way to paraphrase the paragraph above is to

`missing' needs patch for Ultrix4.4

I finally have an account on an Ultrix system and have tracked down a couple problems. The first was that `missing --run :' would fail like this: (the other is in autoconf) $ sh missing --run : sh: : not found WARNING: `:' is needed, and you do not seem to have it handy on your This patch

Re: `missing' needs patch for Ultrix4.4

Alexandre Oliva [EMAIL PROTECTED] wrote: | On Mar 17, 2001, Jim Meyering [EMAIL PROTECTED] wrote: | | * missing (--run): Use `eval' to run `"$@"'. Otherwise, Ultrix4.4's | /bin/sh fails and outputs garbage. | | Won't this evaluate the arguments one too many time

Re: `missing' needs patch for Ultrix4.4

Akim Demaille [EMAIL PROTECTED] wrote: | | Alexandre Oliva [EMAIL PROTECTED] wrote: | | | On Mar 17, 2001, Jim Meyering [EMAIL PROTECTED] wrote: | | | | | | * missing (--run): Use `eval' to run `"$@"'. Otherwise, Ultrix4.4's | | | /bin/sh fails and outpu

Re: `missing' needs patch for Ultrix4.4

Akim Demaille [EMAIL PROTECTED] wrote: | "Jim" == Jim Meyering [EMAIL PROTECTED] writes: | | Jim IMHO, it is always best to `do it right'. Evaluating `$1' one | Jim extra time is probably just fine for all current uses of `missing | Jim --run PROG_AND_ARGS', but someone may well h

Re: `missing' needs patch for Ultrix4.4

Akim Demaille [EMAIL PROTECTED] wrote: | "Jim" == Jim Meyering [EMAIL PROTECTED] writes: | | Jim Hi Akim, | | Jim So consider a name containing some other shell meta-character. | | I don't understand what difference you make between the two approaches | wrt meta-characters. | | Wer a

Re: `missing' needs patch for Ultrix4.4

Tom Tromey [EMAIL PROTECTED] wrote: | "Jim" == Jim Meyering [EMAIL PROTECTED] writes: | | Jim * missing (--run): Use `eval' to run `"$@"'. Otherwise, Ultrix4.4's | Jim /bin/sh fails and outputs garbage. | | Jim - "$@" exit 0 | Jim + eval "$@"

Re: `missing' needs patch for Ultrix4.4

Tom Tromey [EMAIL PROTECTED] wrote: | Jim It was only a problem when $@ was a shell built-in, like : or cd. | | Ok, I re-read your message. Why do we ever run `missing --run :'? | That seems weird. I didn't know off hand either, but found this in automake/m4/missing.m4: # AM_MISSING_HAS_RUN

install-strip rule doesn't work

m4/strip.m4. We want the make variable, $(INSTALL) not the shell variable. [I prefer parens to curly braces, but have left the braces, in case they're there for a good reason] Here's a patch that should work: 2001-04-30 Jim Meyering [EMAIL PROTECTED] * m4/strip.m4: Fix a typo: s

proposed change for depout.m4

Does anyone know of a system for which `head -n1' doesn't work the same as the traditional `head -1'? The latter doesn't conform to POSIX 1003.1-2001. Without this patch, dependencies don't work when using `head' from the next test release of the GNU textutils and with the

Re: proposed change for depout.m4

=`AS_DIRNAME($mf)` else dirpart= Ralf Corsepius [EMAIL PROTECTED] wrote: Am Son, 2002-02-17 um 18.19 schrieb Jim Meyering: Does anyone know of a system for which `head -n1' doesn't work the same as the traditional `head -1'? From SunOS4's manpage (dated ~1990): ...

Re: proposed change for depout.m4

Alexandre Duret-Lutz [EMAIL PROTECTED] wrote: On Sun, Feb 17, 2002 at 08:35:31PM +0100, Jim Meyering wrote: * m4/depout.m4: Don't use `head -1'; it's no longer portable. Use `sed 1q' instead. Hi Jim! Could you adjust tests/cond12.test and tests/insthook.test similarly? Sure

suggestion for lib-link.m4: require config.rpath

is that config.rpath is not in those tarballs. I only noticed it a few minutes ago when I actually watched the output of configure and noticed the error message about the missing file: config/config.rpath. Any objections? 2002-03-05 Jim Meyering [EMAIL PROTECTED] * automake.in (@common_files): Add

FYI: install-sh: work with names containing spaces

a\ b* I've just checked in this change: 2002-11-09 Jim Meyering [EMAIL PROTECTED] Make install-sh work even when names contain spaces or certain (but not all) shell metachars. * lib/install-sh: Remove lots of unnecessary quoting. Add double quotes where

multiple definition of e.g., bin_PROGRAMS

Hi Alexandre! I noticed recently that there are two definitions of bin_PROGRAMS in coreutils' src/Makefile.in. One that's identical to the original in src/Makefile.am, and another, better one, that follows most of the rules copied from Makefile.am. Is this intentional? That doesn't seem like a

Re: warning about _-variables

Alexandre Duret-Lutz [EMAIL PROTECTED] wrote: ... Jim What do you think about dropping that warning altogether, Jim or at least allowing packages like the coreutils to Jim disable that part of -Wall? ... How can we do this? Shall we split -Wportability into two options? How would you

Re: aclocal 1.8 no longer loads overridden macros

Alexandre Duret-Lutz [EMAIL PROTECTED] wrote: Andreas With aclocal 1.8 you no longer get overridden standard Andreas autoconf macros loaded from local *.m4 files. I could not reproduce this (tried to redefine AC_PROG_CC successfully). Can you send detailed instructions? [...]

race condition gnulib-tool's mostlyclean-local rule

For some modules (e.g., sys_stat), gnulib-tool generates a mostlyclean-local rule like this: mostlyclean-local: @test -z $(MOSTLYCLEANDIRS) ||\ for dir in $(MOSTLYCLEANDIRS); do \ if test -d $$dir; then \ echo rmdir $$dir; rmdir

Re: race condition gnulib-tool's mostlyclean-local rule

Ralf Wildenhues [EMAIL PROTECTED] wrote: ... IMVHO it's ugly (and resource-wasting) to have a $(MAKE) reinvocation to paper over limitations in the extensibility of Automake-generated Makefiles; the right fix would be to add dependency information mostlyclean-local: mostlyclean-compile

Re: multiple cpu's

Ralf Wildenhues [EMAIL PROTECTED] wrote: ... OK, so it generates Makefile's that are fully capable of handling the -j switch to make? Mostly. Problems should be reported, please include a copy of the make output of the failed build. Hi Ralf, On a related note, it'd sure be nice if make -j4

Re: multiple cpu's

Benoit SIGOURE [EMAIL PROTECTED] wrote: On Aug 12, 2007, at 11:09 PM, Ralf Wildenhues wrote: Hello Jim, * Jim Meyering wrote on Sun, Aug 12, 2007 at 12:46:20PM CEST: On a related note, it'd sure be nice if make -j4 check would run its tests in parallel. Especially on an SMP system

read-only git mirror of automake cvs repository

I've set up a read-only git mirror of the automake cvs repository: http://sources.redhat.com/git/gitweb.cgi?p=automake.git It is updated from cvs every 15 minutes, but due to the way cvsps works, it may take two iterations for a change in cvs to propagate into the git tree.

Re: read-only git mirror of automake cvs repository

Benoit SIGOURE [EMAIL PROTECTED] wrote: On Oct 8, 2007, at 5:05 PM, Jim Meyering wrote: I've set up a read-only git mirror of the automake cvs repository: Thank you! http://sources.redhat.com/git/gitweb.cgi?p=automake.git --18:05:43-- http://sources.redhat.com/git/automake.git

NEWS: added support for lzma compression

FYI, I added support for LZMA[1] compression a few days ago: http://lists.gnu.org/archive/html/automake-patches/2007-10/msg3.html So now you can put this in your configure.ac file AM_INIT_AUTOMAKE([dist-lzma]) and make dist will generate both .gz and .lzma compressed tarballs. This

Re: not hardwiring gpg

Ralf Wildenhues [EMAIL PROTECTED] wrote: ... So, please commit, and e.g., put the first paragraph of your reply in the log. Ah. That makes sense. Done.

Re: lzip support

Jan Engelhardt [EMAIL PROTECTED] wrote: On Friday 2008-11-28 17:21, Bob Friesenhahn wrote: Since LZIP support has appeared apparently out of the blue (no prior discussion on this list), and Automake already had LZMA support, can someone please explain LZIP vs LZMA and why we now have at least

Re: lzip support

Jan Engelhardt [EMAIL PROTECTED] wrote: On Saturday 2008-11-29 10:06, Jim Meyering wrote: Jan Engelhardt [EMAIL PROTECTED] wrote: On Friday 2008-11-28 17:21, Bob Friesenhahn wrote: Since LZIP support has appeared apparently out of the blue (no prior discussion on this list), and Automake

Re: lzip support

Bob Friesenhahn [EMAIL PROTECTED] wrote: On Sat, 29 Nov 2008, Jim Meyering wrote: I have been following lzma-utils development closely for some time, and my impression is that xz obviates lzip. I would not want to encourage use of lzip without a convincing argument to the contrary. As soon

[PATCH] build: use automake's --silent-rules option when possible

chmod ... rather than less-readable lines full of gcc command-line options. From 9f39fa8559a8f87e1199f11f6cee295ac8cf6781 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Sat, 28 Mar 2009 12:48:24 +0100 Subject: [PATCH] build: use automake's --silent-rules option when

choosing the default for silent-rules

What if a package maintainer wants to enable automake's silent-rules option by default? Currently, even when I use AM_INIT_AUTOMAKE([silent-rules]) it's disabled, and to get the behavior I want, I have to run ./configure --enable-silent-rules or make V=0. Is there a recommended way to make the

Re: choosing the default for silent-rules

Ralf Wildenhues wrote: * Jim Meyering wrote on Sun, Apr 19, 2009 at 10:53:40AM CEST: What if a package maintainer wants to enable automake's silent-rules option by default? Then you should argue for this; see the arguments against it here: ... Hi Ralf, I think backwards compatibility

Re: choosing the default for silent-rules

Ralf Wildenhues wrote: * Jim Meyering wrote on Sun, Apr 19, 2009 at 01:34:50PM CEST: Switching to silent-rules feels like progress, so I want it to be enabled by default, at least for packages I maintain. Of course, that's my judgment, and if enough people say that my enabling silent-rules

using color-tests backwards-portably

Hi Ralf, I'd like to use automake-1.11's color-tests option in libguestfs -- and more importantly, parallel-tests, but we may have a build-from-clone requirement on systems with automake older than 1.11. On those systems, it's fine to ignore or disable these two unsupported options. I proposed a

Re: stable coreutils-8.1 today, fingers crossed

Alan Curry wrote: Jim Meyering writes: Gilles Espinasse wrote: ... [chroot-i486] root:/$ umask 0022 [chroot-i486] root:/$ rm -rf /usr/src/coreutils* [chroot-i486] root:/$ cd /usr/src [chroot-i486] root:/usr/src$ tar xf cache/coreutils-8.1.tar.gz [chroot-i486] root:/usr/src$ ls -ld

Re: permissions of files in dist tarball

Ralf Wildenhues wrote: Hello Alan, Jim, * Jim Meyering wrote on Sun, Nov 22, 2009 at 04:32:57PM CET: Alan Curry wrote: So was the drwxrwxrwx in the tarball put there to teach a lesson to those who trust a tarball to have sane permissions? Or is it a bug? On one hand, you can also think

Re: writability of directories in distributions

Harlan Stenn wrote: I just saw a patch go by about changing the perms on directories in distribution tarballs. I'm a fan of 775 myself (ok, I really prefer 2775). But I can see that some would prefer 777, and others would prefer 755. The other issue, as I recall, has to do with whether or

Re: writability of directories in distributions

Bob Friesenhahn wrote: On Sat, 28 Nov 2009, Harlan Stenn wrote: I just saw a patch go by about changing the perms on directories in distribution tarballs. I'm a fan of 775 myself (ok, I really prefer 2775). But I can see that some would prefer 777, and others would prefer 755. The other

Re: [PATCH] maint.mk (null_AM_MAKEFLAGS, built_programs): remove unused definitions

Paolo Bonzini wrote: On 12/13/2009 10:31 AM, Jim Meyering wrote: -# Use this to make sure we don't run these programs when building -# from a virgin tgz file, below. -null_AM_MAKEFLAGS = \ - ACLOCAL=false \ - AUTOCONF=false \ - AUTOMAKE=false \ - AUTOHEADER=false \ - MAKEINFO=false

Re: [PATCH] maint.mk (null_AM_MAKEFLAGS, built_programs): remove unused definitions

Ralf Wildenhues wrote: * Jim Meyering wrote on Sun, Dec 13, 2009 at 11:44:15AM CET: Paolo Bonzini wrote: This rule could actually be moved to Automake's distcheck target. Good idea. FYI, here's the definition I have now: (added GPERF and LIBTOOL, and made it overridable) Hi Ralf, Good

Re: dist-xz compression level

Pavel Sanda wrote: the newly added dist-xz target produce worse compressed archives than lzma-dist. The reason is that automake call lzma with best compression while it won't use -9 level for xz. Is this intention or bug? It was deliberate. For my use, xz -9 is far too slow for anything

Re: dist-xz compression level

Pavel Sanda wrote: Pavel Sanda wrote: It was deliberate. For my use, xz -9 is far too slow for anything except the final make dist I run just prior to a release. For a release, I run this, via one of the alpha, beta or stable targets in gnulib's maint.mk: $(MAKE) dist XZ_OPT=-9ev Is

Re: absolute build directory with spaces

Bruno Haible wrote: Jim Meyering wrote on bug-gnulib: Coreutils tests with an absolute build directory name that contains a space. Not quoting this directory name caused a failure. * tests/test-vc-list-files-git.sh: Quote PATH dir name. ... --- a/tests/test-vc-list-files-git.sh +++ b/tests

Re: absolute build directory with spaces

Stefano Lattarini wrote: On Saturday 04 September 2010, Bruno Haible wrote: Hi, Jim Meyering wrote on bug-gnulib: Coreutils tests with an absolute build directory name that contains a space. Not quoting this directory name caused a failure. * tests/test-vc-list-files-git.sh: Quote PATH

Re: [coreutils] debbugs

Ralf Wildenhues wrote: [ sorry for the xpost; please followup to the automake list, replyto set ] Hello coreutils developers, Gary was nice to point us at the debbugs you're using now for your bugs list. How do you like it, how's it working for you, Hi Ralf, yes I'm happy with it. it can

bug#8621: build-aux/compile: avoid race condition failure

Is there any reason not to make the compile script accommodate (in a race-free manner) situations like the one described in http://debbugs.gnu.org/8616 ?

Re: bug#8616: conflict between build-aux/compile script and coreutils Makefiles

Stefano Lattarini wrote: On Thursday 05 May 2011, Jim Meyering wrote: Green, Paul wrote: Gentle Coreutils Developers, [HUGE CUT] To the automake folks, is there any reason not to do that? Hi Jim. I'm in a middle of something else right now, so I'm probably not going to look

Re: bug#8616: conflict between build-aux/compile script and coreutils Makefiles

Green, Paul wrote: Gentle Coreutils Developers, I am writing to notify you of an issue that I stumbled across while building coreutils-8.12 on the Stratus OpenVOS platform. Hi Paul, Thanks for the detailed report. I'm Cc'ing the automake list, since that's the source of the compile script.

Re: [RFC] Releasing automake 1.11.2

Stefano Lattarini wrote: Hello automakers. I think it's about time to release automake 1.11.2 -- the `maint' branch contains various bug fixes w.r.t. the 1.11.1 release (some of them quite important), and offers some new small features and various warnings/deprecations that should prepare

Re: [RFC] Releasing automake 1.11.2

Stefano Lattarini wrote: References: http://lists.gnu.org/archive/html/automake/2011-10/msg6.html http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10026 At this point I think we are ready to release a beta version of 1.11.2, and then ask for help on platform-testers to smoke out some more

Re: GNU Automake 1.12.1 released

Stefano Lattarini wrote: On 07/06/2012 12:10 AM, Diego Elio Pettenò wrote: Il 05/07/2012 11:26, Stefano Lattarini ha scritto: How so? Removal of $(mkdir_p) is only planned for Automake 1.13, that is still unreleased. Ehm Stefano, that's definitely not the case, I've been hitting that issue

Re: GNU Automake 1.12.1 released

Stefano Lattarini wrote: On 07/09/2012 09:22 AM, Jim Meyering wrote: Hi Stefano, I see that @mkdir_p@ is used in gettext's Makefile.in.in template: # We use $(mkdir_p). # In automake = 1.9.x, $(mkdir_p) is defined either as mkdir -p -- or as # $(mkinstalldirs) or as $(install_sh) -d

Re: GNU Automake 1.12.1 released

Stefano Lattarini wrote: On 07/09/2012 11:45 AM, Stefano Lattarini wrote: On 07/09/2012 11:17 AM, Jim Meyering wrote: - - The long-obsolete (since automake 1.10) @mkdir_p@ configure-time -substitution and AM_PROG_MKDIR m4 macro will be removed in Automake -1.13. The $(mkdir_p

parallel make check output lines are lost!?!

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 -C tests VERBOSE=yes \ RUN_EXPENSIVE_TESTS=no makerr-$i t=.||t=X; printf $t; done They all passed, but I decided to compare a few, in

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

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

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

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

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: [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: [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

[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 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: 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

[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] "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

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 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

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 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] 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: __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: 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

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: 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

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

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: 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

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: 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.

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: [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.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: 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.

  1   2   3   >