Re: REPLACE_GNU_GETOPT

[Jim Meyering]

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 completely implemented.  It is in automake, and the info file,
| Hal but nowhere else I could see.  Is this functionality going away?
| Hal How can I properly do what I want to do?  I don't know perl, so I
| Hal am somewhat limited in my ability to read the source.
|
| This stuff you found is sort of a relic from the old days, when
| automake was more or less used only by the Gnits people.
| AC_REPLACE_GNU_GETOPT was never in automake, as I recall.
| You just had to know where to get it :-(
| Perhaps Jim has a copy.  Jim?

I don't have a copy in *utils.
IMHO, it's totally obsolete/unnecessary, now.
Here's what I wrote in late 1996 (now it's in fileutils/ChangeLog-1997):

* configure.in (AC_REPLACE_GNU_GETOPT): Remove it -- it's not
necessary.

Most packages simply compile getopt.c and getopt1.c unconditionally.

test pr19 failure: explanation

[Jim Meyering]

I've just looked into the failure of test pr19.
The distdir rules copying these four files (in the $(DISTFILES) list)
from ../:
  depcomp
  install-sh
  missing
  mkinstalldirs

Of course, those files aren't removed by `make distclean', and hence the
`find...|wc' in the distcheck rules counts four files rather than the
expected `0'.  Since I haven't even looked to see what pr#19 is about,
there's a good chance this patch just papers over a larger problem...

Index: tests/ChangeLog
===
RCS file: /cvs/automake/automake/tests/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:
+   depcomp, install-sh, missing, mkinstalldirs.
+
 2000-02-02  Assar Westerlund  [EMAIL PROTECTED]
 
* target-cflags.test: new test case to target-specific CFLAGS
@@ -1240,4 +1245,3 @@ Sat Feb 10 17:08:39 1996  Tom Tromey  t
* mdate.test, vtexi.test, acoutput.test: New files.
 
* Started.
-
Index: tests/pr19.test
===
RCS file: /cvs/automake/automake/tests/pr19.test,v
retrieving revision 1.3
diff -u -p -r1.3 pr19.test
--- pr19.test   1999/12/27 07:40:32 1.3
+++ pr19.test   2000/03/04 11:34:19
@@ -23,6 +23,8 @@ LDADD = @LEXLIB@
 
 noinst_PROGRAMS   = foo
 foo_SOURCES   = foo.l
+
+DISTCLEANFILES = depcomp install-sh missing mkinstalldirs
 END
 
 # Remove some files installed by defs.  These will be reinstalled by

Re: Autoconf regex test

[Jim Meyering]

Geoff Hutchison [EMAIL PROTECTED] writes:
| I need some help on writing a rather strange autoconf test. If this seems
| painfully obvious, I'm sorry, I'm just drawing a blank.
|
| My GPL'ed package includes the glibc regex.c source. Right now, this
| causes segfaults on BSDI and Digital Unix. I'm in the process of working
| out why this happens, but in the meantime, I'd like a test to see whether
| the included regex.o should be compiled and linked in.
|
| Basically, I want an AC_TRY_RUN test that includes the regex.c file in
| compilation. Is this possible, or can you only compile/link 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])
dnl
AC_DEFUN(jm_INCLUDED_REGEX,
  [
dnl Even packages that don't use regex.c can use this macro.
dnl Of course, for them it doesn't do anything.

# Assume we'll default to using the included regex.c.
ac_use_included_regex=yes

# However, if the system regex support is good enough that it passes the
# the following run test, then default to *not* using the included regex.c.
# If cross compiling, assume the test would fail and use the included
# regex.c.  The first failing regular expression is from `Spencer ere
# test #75' in grep-2.3.
AC_CACHE_CHECK([for working re_compile_pattern],
   jm_cv_func_working_re_compile_pattern,
  AC_TRY_RUN(
[#include stdio.h
#include regex.h
  int
  main ()
  {
static struct re_pattern_buffer regex;
const char *s;
re_set_syntax (RE_SYNTAX_POSIX_EGREP);
/* Add this third left square bracket, [, to balance the
   three right ones below.  Otherwise autoconf-2.14 chokes.  */
s = re_compile_pattern ("a[[:]:]]b\n", 9, regex);
/* This should fail with _Invalid character class name_ error.  */
if (!s)
  exit (1);

/* This should succeed, but doesn't for e.g. glibc-2.1.3.  */
s = re_compile_pattern ("{1", 2, regex);

exit (s ? 1 : 0);
  }
],
   jm_cv_func_working_re_compile_pattern=yes,
   jm_cv_func_working_re_compile_pattern=no,
   dnl When crosscompiling, assume it's broken.
   jm_cv_func_working_re_compile_pattern=no))
if test $jm_cv_func_working_re_compile_pattern = yes; then
  ac_use_included_regex=no
fi

test -n "$1" || AC_MSG_ERROR([missing argument])
syscmd([test -f $1])
ifelse(sysval, 0,
  [

AC_ARG_WITH(included-regex,
[  --without-included-regex don't compile regex; this is the default on
  systems with version 2 of the GNU C library
  (use with caution on other system)],
jm_with_regex=$withval,
jm_with_regex=$ac_use_included_regex)
if test "$jm_with_regex" = yes; then
  AC_SUBST(LIBOBJS)
  LIBOBJS="$LIBOBJS regex.$ac_objext"
fi
  ],
)
  ]
)

Re: patch: AC_CONFIG_HEADERS

[Jim Meyering]

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

[Jim Meyering]

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
am_conf_line_error ($filename, $., "\`$1' is obsolete$hint");
}
 
-   # Process the AC_OUTPUT macro.
-   if (! $in_ac_output  s/AC_OUTPUT\s*\(\[?//)
+   # Process the AC_OUTPUT and AC_CONFIG_FILES macros.
+   if (! $in_ac_output  s/AC_(OUTPUT|CONFIG_FILES)\s*\(\[?//)
{
$in_ac_output = 1;
$ac_output_line = $.;

| From: Harlan Stenn [EMAIL PROTECTED]
| Subject: Re: obsolete AC_OUTPUT_COMMANDS in AM_CONFIG_HEADER
| To: Akim Demaille [EMAIL PROTECTED]
| cc: Erez Zadok [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
| Date: Tue, 08 Feb 2000 20:44:52 -0500
|
| This patch seems to work for me to solve the problem of splitting the
| original AC_OUTPUT(...) into AC_CONFIG_FILES(...) and AC_OUTPUT.
|
| It applies just as easily to automake.in .
|
| --- /usr/local/gnu/bin/automake   Mon Dec 20 00:09:39 1999
| +++ automake  Sun Jan 23 17:19:31 2000
| @@ -4397,6 +4397,12 @@
|   $in_ac_output = 1;
|   $ac_output_line = $.;
|   }
| + # Process the AC_CONFIG_FILES macro.
| + if (! $in_ac_output  s/AC_CONFIG_FILES\s*\(\[?//)
| + {
| + $in_ac_output = 1;
| + $ac_output_line = $.;
| + }
|   if ($in_ac_output)
|   {
|   local ($closing) = 0;
|
|
| --

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

[Jim Meyering]

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
| applied.
|
| Akim
|
| | 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
| | am_conf_line_error ($filename, $., "\`$1' is obsolete$hint");
| | }
| |
| | -   # Process the AC_OUTPUT macro.
| | -   if (! $in_ac_output  s/AC_OUTPUT\s*\(\[?//)
| | +   # Process the AC_OUTPUT and AC_CONFIG_FILES macros.
| | +   if (! $in_ac_output  s/AC_(OUTPUT|CONFIG_FILES)\s*\(\[?//)
| | {
| | $in_ac_output = 1;
| | $ac_output_line = $.;
| |

Re: Patch: init.m4

[Jim Meyering]

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 for config.h.in are true sentences:
|
| Define to the name of the package.

Right.  If it's a sentence, then I prefer to capitalize the first word
and put a period at the end :-)  If it's not a sentence, it's a tiny bit
better not to capitalize, but I didn't think it was worth the trouble of
changing those two.  Besides, IMHO, it's best not to mix such formatting
changes with `real' ones.

Re: Patch: init.m4

[Jim Meyering]

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.])])

2000-05-01  Akim Demaille  [EMAIL PROTECTED]

* m4/init.m4 (AC_PROVIDE_IFELSE): If it is not defined, do it.
(AM_INIT_AUTOMAKE): Update the writing conventions.
Quote the arguments properly.
Add a few missing `dnl'.
Use AC_PROVIDE_IFELSE.

| | Index: m4/init.m4
| | ===
| | RCS file: /cvs/automake/automake/m4/init.m4,v
| | retrieving revision 1.17
| | diff -u -r1.17 init.m4

Re: [patch]: recognize AC_LIBOBJ

[Jim Meyering]

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 debate -- they should just go in.  The only
| exception is if the patch breaks compatability with the current
| released autoconf.

Argh.
Bad day.  But at least I caught it myself, before the commit.
Here's a better patch:

Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.786
diff -u -p -r1.786 automake.in
--- automake.in 2000/05/12 00:02:29 1.786
+++ automake.in 2000/07/02 19:14:03
@@ -4373,6 +4373,10 @@ sub scan_one_configure_file
}
}
}
+   elsif (/AC_LIBOBJ\(([^)]+)\)/)
+   {
+   $libsources{"$1.c"} = 1;
+   }
 
if (! $in_ac_replace  s/AC_REPLACE_FUNCS\s*\(\[?//)
{

m4/header.m4 has several problems (patch)

[Jim Meyering]

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 last change:
add missing closing bracket and closing parenthesis.
Don't quote the first argument to AC_OUTPUT_COMMANDS.
Backslash-escape the backquotes and `$' in `am_indx'-incrementing stmt.

I'll do some more testing, then (barring any problems)
check this in tomorrow.

Index: m4/header.m4
===
RCS file: /cvs/automake/automake/m4/header.m4,v
retrieving revision 1.6
diff -u -p -r1.6 header.m4
--- header.m4   2000/08/02 08:59:16 1.6
+++ header.m4   2000/08/05 13:23:19
@@ -1,6 +1,6 @@
 # Like AC_CONFIG_HEADER, but automatically create stamp file.
 
-# serial 2
+# serial 3
 
 # When config.status generates a header, we must update the stamp-h file.
 # This file resides in the same directory as the config header
@@ -11,17 +11,18 @@ AC_PREREQ([2.12])
 
 AC_DEFUN([AM_CONFIG_HEADER],
 [AC_CONFIG_HEADER([$1])
-AC_OUTPUT_COMMANDS(
-[ifelse(patsubst([$1], [[^ ]], []),
-[],
-[test -z "$CONFIG_HEADERS" || echo timestamp dnl
- patsubst([$1], [^\([^:]*/\)?.*], [\1])stamp-h])],
-[am_indx=1
-for am_file in $1; do
-  case " $CONFIG_HEADERS " in
-  *" $am_file "*)
-echo timestamp  `echo $am_file | sed 's%:.*%%;s%[^/]*$%%'`stamp-h$am_indx
-;;
-  esac
-  am_indx=`expr "$am_indx" + 1`
-done])
+  AC_OUTPUT_COMMANDS(
+   ifelse(patsubst([$1], [[^ ]], []),
+ [],
+ [test -z "$CONFIG_HEADERS" || echo timestamp dnl
+  patsubst([$1], [^\([^:]*/\)?.*], [\1])stamp-h]),
+  [am_indx=1
+  for am_file in $1; do
+case " $CONFIG_HEADERS " in
+*" $am_file "*)
+  echo timestamp  `echo $am_file | sed 's%:.*%%;s%[^/]*$%%'`stamp-h$am_indx
+  ;;
+esac
+am_indx=\`expr \$am_indx + 1\`
+  done])
+])

Re: subdir4.test

[Jim Meyering]

You're welcome to apply your change.
I suppose (since tests pass without it) something has
changed to make that code unnecessary.

Akim Demaille [EMAIL PROTECTED] writes:
...
| but the problem is that Jim made this on purpose I guess since:

I have been known to check in changes accidentally :-)
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: Put depcomp into subdir.
| | * confsub.test: Put depcomp into subdir.
| | * defs: Always copy `depcomp'.
|
| his introduction of subdir4.test was made after that `defs' copies
| `depcomp'.  Since I don't understand too well what was your intention,
| Jim, I didn't apply it.  But with this patch, Automake checks and
| distchecks.

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

[Jim Meyering]

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 say that now
|  Akim `Makefile' and `config.h' have the same status wrt `all').  I
|  Akim was very unsure of the status of $(BUILT_SOURCES) and made it
|  Akim config.h-like, while $(DATA)-like was another valid choice.
| 
|  You have to be careful touching BUILT_SOURCES.  In the past we forced
|  them to be built as a condition of building (`Makefile: $(BUILT_SOURCES)').
|  That is wrong.
|
| Jim has this in the fileutils/src/Makefile.am:
|
| Makefile: $(BUILT_SOURCES)

Thanks for pointing that out.
And thank you, Tom, for fixing automake so I no longer need the kludge.
I've fixed it.

`missing' needs patch for Ultrix4.4

[Jim Meyering]

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 seems to preserve the semantics and avoids the problem:

* missing (--run): Use `eval' to run `"$@"'.  Otherwise, Ultrix4.4's
/bin/sh fails and outputs garbage.

If anyone sees a problem with this, let me know.

Index: missing
===
RCS file: /fetish/fileutils/missing,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- missing 2001/03/16 08:37:01 1.6
+++ missing 2001/03/17 22:12:34 1.7
@@ -30,7 +30,7 @@
   # Try to run requested program, and just exit if it succeeds.
   run=
   shift
-  "$@"  exit 0
+  eval "$@"  exit 0
   ;;
 esac
 

Re: `missing' needs patch for Ultrix4.4

[Jim Meyering]

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

Thanks!  You're right.

| How about:
|
| prog=$1
| shift
| $prog ${1+"$@"}  exit 0

But wouldn't that'd have the same problem, in the unlikely event
that $1 contains shell meta-characters.  How about this instead?

Index: missing
===
RCS file: /cvs/automake/automake/missing,v
retrieving revision 1.12
diff -u -p -r1.12 missing
--- missing 2000/10/16 09:01:36 1.12
+++ missing 2001/03/19 08:54:35
@@ -30,7 +30,16 @@ case "$1" in
   # Try to run requested program, and just exit if it succeeds.
   run=
   shift
-  "$@"  exit 0
+  # This is convoluted because using `"$@"  exit 0' doesn't
+  # work with some shells (at least Ultrix4.4's /bin/sh).
+  case "$@" in
+:)
+  :  exit 0
+  ;;
+*)
+  ( exec "$@" )  exit 0
+  ;;
+  esac
   ;;
 esac
 

Re: `missing' needs patch for Ultrix4.4

[Jim Meyering]

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 outputs garbage.
| | |
| | | Won't this evaluate the arguments one too many times?
| |
| | Thanks!  You're right.
| |
| | | How about:
| | |
| | | prog=$1
| | | shift
| | | $prog ${1+"$@"}  exit 0
|
| I was about to suggest the same.
|
| | But wouldn't that'd have the same problem, in the unlikely event
| | that $1 contains shell meta-characters.  How about this instead?
|
| Given that "$@" is expected to be valid a valid shell command, there
| should be no new problems, "$@" takes everything in charge.  In
| addition, the idiom above is very common, so it must be sound.

IMHO, it is always best to `do it right'.
Evaluating `$1' one extra time is probably just fine
for all current uses of `missing --run PROG_AND_ARGS',
but someone may well have to use it on a program whose
name contains spaces.  We shouldn't prohibit that.

Here's an example showing the difference.
With my latest suggested change it works:

  $ echo '#!/bin/sh'  'cat file'
  $ chmod a+x !$
  chmod a+x 'cat file'
  $ PATH=$PATH:. sh missing --run 'cat file'

With what Alexandre suggested, it fails:

  $ PATH=$PATH:. sh missing --run 'cat file'
  cat: file: No such file or directory
  WARNING: `' is needed, and you do not seem to have it handy on your
   system.  You might have modified some files without having the
   proper tools for further handling them.  Check the `README' file,
   it often tells you about the needed prerequirements for installing
   this package.  You may also peek at any GNU archive site, in case
   some other package would contain this missing `' program.
  [Exit 1]

Re: `missing' needs patch for Ultrix4.4

[Jim Meyering]

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 have to use it on a
| Jim program whose name contains spaces.  We shouldn't prohibit that.
|
| In theory, I agree with you, but we are talking about Make too, and
| the motto up to now was ``forget about spaces in filenames as Make
| makes it impossible''.

Hi Akim,

So consider a name containing some other shell meta-character.  I know
that using such names is not recommended, but I don't like to make
changes that cause programs to fail unnecessarily in any case.  And what
if someone wants to use `missing' in a build system that doesn't have
make's limitation?

It's not as if the change I suggested is *that* ugly, is it?

It doesn't seem right to change `missing' to work less well on _all_
systems just to work around a broken shell on Ultrix4.4.  Granted, the
new failure would happen only when given some presumably `unusual' inputs.

Jim

Re: `missing' needs patch for Ultrix4.4

[Jim Meyering]

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 are talking about
|
| ( exec "$@" )
|
| vs
|
| prog=$1
| shift
| "$prog" "$@"

His suggested change didn't have double quotes around $prog.
Besides, if you do use double quotes around it, as you've written, above,
then Ultrix4.4's /bin/sh fails in exactly the same way as if you'd used "$@".

| and I see no difference wrt meta-characters.
|
| | /tmp % cat cat\ file
| | #! /bin/cat
| | /tmp % cat foo.sh
| | #! /bin/sh
| |
| | # Jim.
| | ( exec "$@" )
| |
| | # Alexandre
| | prog=$1
| | shift
| | "$prog" ${1+"$@"}
| | /tmp % PATH=/tmp ./foo.sh 'cat file' 'cat file'
| | #! /bin/cat
| | #! /bin/cat
| | #! /bin/cat
| | #! /bin/cat

Re: `missing' needs patch for Ultrix4.4

[Jim Meyering]

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 "$@"  exit 0
|
| I read through this thread but didn't see convergence on a solution.
| Do we know what to do?
| Won't this problem also affect `depcomp'?  And maybe other scripts?
| Or is it only an issue when $1 is "weird" (eg `:')?

Hi Tom,

It was only a problem when $@ was a shell built-in, like : or cd.

Re: `missing' needs patch for Ultrix4.4

[Jim Meyering]

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
  # --
  # Define MISSING if not defined so far and test if it supports --run.
  # If it does, set am_missing_run to use it, otherwise, to nothing.
  AC_DEFUN([AM_MISSING_HAS_RUN],
  [test x"${MISSING+set}" = xset ||
MISSING="\${SHELL} `CDPATH=:; cd $ac_aux_dir  pwd`/missing"
  # Use eval to expand $SHELL
  if eval "$MISSING --run :"; then
am_missing_run="$MISSING --run "
  ...

install-strip rule doesn't work

[Jim Meyering]

Hi Bob,

Thanks for reporting that.
It seems to be a bug that's still in the current sources.

In fileutils-4.1/src/Makefile, I see this:

  INSTALL_STRIP_PROGRAM = $${INSTALL} -s

which eventually expands to just ` -s' and produces the
symptom Bob noted below.

The problem comes from automake's 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/\$\$/$/.



--- m4/strip.m4.~1~ Mon Feb 19 05:11:57 2001
+++ m4/strip.m4 Mon Apr 30 11:13:36 2001
@@ -30,7 +30,7 @@ if test -z $STRIP; then
   # is substitued in the sub-makes, not at the top-level; this is
   # needed if ${INSTALL} is a relative path (ajusted in each subdirectory
   # by config.status).
-  INSTALL_STRIP_PROGRAM='$${INSTALL} -s'
+  INSTALL_STRIP_PROGRAM='${INSTALL} -s'
   INSTALL_STRIP_PROGRAM_ENV=''
 else
   _am_dirpart=`echo $install_sh | sed -e 's,//*[[^/]]*$,,'`

Bob Proulx [EMAIL PROTECTED] wrote:
| Jim
...
| I just happened to try something new today.  I tried to use the newer
| make target install-strip that the later automake provides.  It seems
| broken.
|
|   make install-strip
|   /bin/sh ../mkinstalldirs /usr/local/bin
| -s chgrp /usr/local/bin/chgrp
|   /bin/sh: -s:  not found.
|
| BTW, here is the previous method that I am continuing to use for
| production installations.
|
|   make INSTALL_PROGRAM='install -s' install
|
| This had not previously existed and so should not be a concern for
| the, well deserved, release.  But I did want to note it anyway.
|
| Bob

proposed change for depout.m4

[Jim Meyering]

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 `conform-to-latest-POSIX' switch set (via e.g.,
export _POSIX2_VERSION=200112).

I'll check it in if I don't hear anything by tomorrow.

Index: m4/depout.m4
===
RCS file: /cvs/automake/automake/m4/depout.m4,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 depout.m4
--- depout.m4   2001/12/30 20:29:14 1.10
+++ depout.m4   2002/02/17 17:14:58
@@ -25,7 +25,7 @@ AC_DEFUN([_AM_OUTPUT_DEPENDENCY_COMMANDS
 [for mf in $CONFIG_FILES; do
   # Strip MF so we end up with the name of the file.
   mf=`echo $mf | sed -e 's/:.*$//'`
-  if (head -1 $mf | fgrep 'generated by automake')  /dev/null 21; then
+  if (head -n1 $mf | fgrep 'generated by automake')  /dev/null 21; then
 dirpart=`AS_DIRNAME($mf)`
   else
 dirpart=

Re: proposed change for depout.m4

[Jim Meyering]

Thanks!  You're right.  I've just confirmed that on a
SunOS4.1.4 system its /usr/ucb/head.

Here's a better patch:

* m4/depout.m4: Don't use `head -1'; it's no longer portable.
Use `sed 1q' instead.

Index: m4/depout.m4
===
RCS file: /cvs/automake/automake/m4/depout.m4,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 depout.m4
--- depout.m4   2001/12/30 20:29:14 1.10
+++ depout.m4   2002/02/17 19:34:54
@@ -1,6 +1,6 @@
 # Generate code to set up dependency tracking.   -*- Autoconf -*-
 
-# Copyright 1999, 2000, 2001 Free Software Foundation, Inc.
+# Copyright 1999, 2000, 2001, 2002 Free Software Foundation, Inc.
 
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -25,7 +25,7 @@ AC_DEFUN([_AM_OUTPUT_DEPENDENCY_COMMANDS
 [for mf in $CONFIG_FILES; do
   # Strip MF so we end up with the name of the file.
   mf=`echo $mf | sed -e 's/:.*$//'`
-  if (head -1 $mf | fgrep 'generated by automake')  /dev/null 21; then
+  if (sed 1q $mf | fgrep 'generated by automake')  /dev/null 21; then
 dirpart=`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

[Jim Meyering]

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.  Thanks!
Here are the additional changes I expect to check in tomorrow.

* tests/cond12.test: Use sed 1q, not `head -n 1'.
The latter is not portable to some old systems.
* m4/depout.m4: Don't use `head -1'; it's no longer portable.
Use `sed 1q' instead.
* tests/insthook.test: Likewise.

Index: tests/cond12.test
===
RCS file: /cvs/automake/automake/tests/cond12.test,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 cond12.test
--- cond12.test 2001/07/01 22:51:38 1.1
+++ cond12.test 2002/02/17 21:31:41
@@ -9,7 +9,7 @@
 # FIXME: probably ought to let use override this like we do in `defs'.
 amfile=../../automake
 
-head -n 1 $amfile automake_tmp
+sed 1q $amfile automake_tmp
 cat  'END'  automake_tmp
 my $failed = 0;
 sub check_reduce($$) {
@@ -17,7 +17,7 @@ sub check_reduce($$) {
  my @result = sort Automake::variable_conditions_reduce(@$inref);
  my $correct = 1;
  $correct = 0 if (join(,, @result) ne join(,, @$outref));
- 
+
  if (! $correct) {
print ''.join(,, @$inref) . ' = ' .
 join(,, @result) . ' expected ' .
Index: tests/insthook.test
===
RCS file: /cvs/automake/automake/tests/insthook.test,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 insthook.test
--- insthook.test   2001/10/20 11:17:17 1.4
+++ insthook.test   2002/02/17 21:31:41
@@ -15,4 +15,4 @@ $AUTOMAKE || exit 1
 
 test `grep install-exec-hook Makefile.in | wc -l` -gt 1 || exit 1
 lnum=`grep -n '^install-exec-am:' Makefile.in | awk -F: '{print $1}'`
-test x$lnum != x  tail +$lnum Makefile.in | head -3 | grep install-exec-hook
+test x$lnum != x  tail +$lnum Makefile.in | sed 3q | grep install-exec-hook

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

[Jim Meyering]

I think that automake should add config.rpath to the list of
`@common_files', since that file is required when using the
standard gettext-0.11 infrastructure.

I didn't add that file to Makefile.am's EXTRA_DIST in
both the latest textutils and fileutils test releases.  The result
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 config.rpath.

Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1278
diff -u -p -u -p -r1.1278 automake.in
--- automake.in 2002/02/25 11:00:29 1.1278
+++ automake.in 2002/03/05 10:03:27
@@ -205,7 +205,7 @@ my @libtool_sometimes = qw(ltconfig ltcf
 my @common_files =
 (qw(ABOUT-GNU ABOUT-NLS AUTHORS BACKLOG COPYING COPYING.DOC COPYING.LIB
ChangeLog INSTALL NEWS README THANKS TODO acinclude.m4
-   ansi2knr.1 ansi2knr.c compile config.guess config.sub
+   ansi2knr.1 ansi2knr.c compile config.guess config.rpath config.sub
configure configure.ac configure.in depcomp elisp-comp
install-sh libversion.in mdate-sh missing mkinstalldirs
py-compile texinfo.tex ylwrap),

FYI: install-sh: work with names containing spaces

[Jim Meyering]

Due to insufficient quoting, install-sh fails for names (source or dest)
that contain spaces or some shell meta-characters.  E.g.,

  $ mkdir /tmp/x\ y
  $ touch a\ b
  $ bash install-sh 'a b' /tmp/x\ y
  install-sh: line 150: [: /tmp/x: binary operator expected
  mv: when moving multiple files, last argument must be a directory
  Try `mv --help' for more information.
  [Exit 1]

Plus, there was a bit of unnecessary quoting and some other
minor problems.  I've fixed them, so now this works as it should:

  $ mkdir /tmp/x\ y
  $ touch a\ b
  $ bash install-sh a\ b /tmp/x\ y
  $ ls /tmp/x\ y
  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 necessary.
Write diagnostics to stderr, not stdout.
Normalize spacing in diagnostics: use one space (not two,
and not a TAB) after the leading `install:'.
Remove trailing white space.
Remove unnecessary curly braces.
If removing the destination fails, also try to move it aside.
Use `trap' more portably.
* tests/installsh2.test: New file, to test for the above fix.
* tests/Makefile.am (TESTS): Add installsh2.test.

multiple definition of e.g., bin_PROGRAMS

[Jim Meyering]

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 big problem, but could conceivably cause
trouble, since most of the names in the first definition lack the
$(EXEEXT) suffix, while all of the ones in the latter have it.

Of course, most uses of $(bin_PROGRAMS) will resolve to the latter,
better definition, but if someone ever does something like this

var := $(bin_PROGRAMS)

in Makefile.am, they might be surprised not to get the $(EXEEXT) suffixes.

Poking around in automake.in, I see that append_exeext does call
macro_delete (presumably to remove the original definition), but
by the time that function is invoked, it's already too late: the
first definition has been `output' via generate_makefile's call to
read_main_am_file.

For example, from automake's backsl.test,

  testSubDir/Makefile.am:bin_PROGRAMS = hello
  testSubDir/Makefile.in:bin_PROGRAMS = hello
  testSubDir/Makefile.in:bin_PROGRAMS = hello$(EXEEXT)

The same applies to EXTRA_PROGRAMS, and probably any other
*_PROGRAMS variables that happen to be used.

I'll let you decide whether/how to fix this one :-)

Jim

Re: warning about _-variables

[Jim Meyering]

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 name the other one?  This sounds a bit
 clumsy.  Perhaps it would be better to provide a way to disable
 warnings individually?

I like that idea!
But then you have to choose between names and numbers.
Naming (and documenting!) that many options is hard work.
Numbers aren't as aesthetically pleasing.  Tough choice, and a
significant amount of work either way.  Maybe it's not worth it.
I'll bet that this isn't something that's likely to come up
very often, so maybe I should just patch my copy of automake.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: aclocal 1.8 no longer loads overridden macros

[Jim Meyering]

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?

 [...]

  Andreas running aclocal -I m4 in the coreutils-5.0 source
  Andreas directory does not include the file m4/search-libs.m4
  Andreas in aclocal.m4.

 CC'ed Jim for this.

Thank you both.
I've just done this for coreutils:

* search-libs.m4 (AC_SEARCH_LIBS): Remove file/macro, now that
this replacement is no longer needed.  Besides, this macro has
no effect with autoconf-2.58, since `undefine' in package-supplied
.m4 files is no longer honored.  Reported by Andreas Schwab.

Remove now-unnecessary (and unused) files.  They also used `undefine'.
* isc-posix.m4 (AC_ISC_POSIX): Remove file.
* getloadavg.m4 (gl_FUNC_GETLOADAVG): Remove file.
* prereq.m4 (jm_PREREQ): Require AC_FUNC_GETLOADAVG,
not gl_FUNC_GETLOADAVG.

race condition gnulib-tool's mostlyclean-local rule

[Jim Meyering]

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 $$dir;  \
fi; \
done

It works fine when Make rules are run in sequence.
But I always run make in parallel, e.g., with -j3.
That causes the rmdir to fail if not all MOSTLYCLEANFILES
have been removed when the above rmdir runs.  But if you look
right afterwards, you find that it is indeed empty.
FYI, this triggered a failure in coreutils make distcheck
with some changes I'm working on.

One way to fix it is by changing automake to generate
a slightly different rule.  Currently it emits this:

mostlyclean-am: mostlyclean-compile mostlyclean-generic \
mostlyclean-local

The problem would be solved if automake were to emit this instead:

mostlyclean-am: mostlyclean-compile mostlyclean-generic
$(MAKE) mostlyclean-local

While I wait for an official automake fix, I'm using the more
aggressive -- i.e., slightly risky -- rule in my Makefile.am:

mostlyclean-local:
@test -z $(MOSTLYCLEANDIRS) || rm -rf $(MOSTLYCLEANDIRS)

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

[Jim Meyering]

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

 in this case, except that the latter two targets are not published.

 I suggest that for most *-local targets it supports (i.e., where it
 makes sense), Automake add a set of hooks
   *-local-before
   *-local-after

Hi Ralf,

I prefer that approach, too.
Go for it! :)

Re: multiple cpu's

[Jim Meyering]

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 check would run its
tests in parallel.  Especially on an SMP system, and/or when some
tests sleep for a few (interminable :-) seconds.

Of course, this might not be trivial, especially trying to keep
the resulting Makefile.in portable.  However, even if it means
I'd need to use a special option to generate a GNU-make-only
Makefile.in, I'd happily use the result for day to day work.

Currently, the check-TESTS rule is just a big for-loop.
Recording pass, fail, xfail, and skip subtotals in parallel might
be a challenge, but I'd be happy to sacrifice those along
with portability, in return for parallelized tests.

Re: multiple cpu's

[Jim Meyering]

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, and/or when some
 tests sleep for a few (interminable :-) seconds.

 Of course, this might not be trivial, especially trying to keep
 the resulting Makefile.in portable.  However, even if it means
 I'd need to use a special option to generate a GNU-make-only
 Makefile.in, I'd happily use the result for day to day work.

 IIRC, Akim Demaille posted a patch a while ago on an automake list for
 this, GNU make-specific.  I don't recall how much work was left to do,
 but on my list it's a bit on the far end.


 Yep:
 http://lists.gnu.org/archive/html/automake/2007-02/msg00015.html
 The whole idea is to have one input file per test (say a .chk file)
 that produces a .log file.  We can then benefit from the parallelism
 of make with implicit rules (exactly like for .c - .o).

 The file has slightly evolved since then but I can post an updated
 version if someone is interested.

That'd be great.

FYI, in testing this, I've been using check.mk from vaucanson-trunk.
Is that what you mean?

read-only git mirror of automake cvs repository

[Jim Meyering]

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

[Jim Meyering]

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/info/refs
= `refs'
 Resolving sources.redhat.com... 209.132.176.174
 Connecting to sources.redhat.com|209.132.176.174|:80... connected.
 HTTP request sent, awaiting response... 404 Not Found
 18:05:43 ERROR 404: Not Found.

 git-clone uses curl and ends up saying:
   Cannot get remote repository information.

Thanks.  That happened because I forgot to do this:

  chmod a+x .git/hooks/post-update

   Perhaps git-update-server-info needs to be run there?

The post-update hook runs git-update-server-info
after each update.

 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.

 That's still great.  I wonder how you did this because I already tried
 several times to import the various autotools with git-
 cvsimport and it always miserably failed (for various reasons, but
 mainly because cvsps is a really dirty hack and its code has lots of
 bugs, some of which I had to fix so that it eventually finishes but
 the resulting Git repository had lots of corrupted commits).

I admit it was took more than a few iterations to get it right.
One of the big points was to realize that cvsps' cache was causing
trouble.  So I'm careful to make git-cvsimport run cvsps in such a
way that the cache can't interfere.
One way to do that is to point HOME= at an empty directory
for the git-cvsimport run.

I do have a script to help manage the process, ...
how about if you ping me about it in a week or so.

NEWS: added support for lzma compression

[Jim Meyering]

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 started when I discovered p7zip a few weeks ago and was flabbergasted
to see that it compressed the coreutils tarball to a measly 3.3MB(!),
while bzip2 managed to compress it to only 5.3MB.  The gzip'd tarball
weighs in at 8.4MB.

In addition, it usually decompressed at least twice as fast as bzip2.
My other test case was the emacs tarball.  It compressed it to 24MB,
which was 6MB smaller than the bzip2-compressed size.
Pretty impressive.

lzma uses the same core compression technology (based on 7zip, originally
written for windows), but it's been converted to c99, and its command-line
interface is a lot more like gzip and bzip2.

For now, there is neither a mailing list, nor a publicly accessible
repository for lzma, but with a little luck we'll have both before
too long.

[1] http://tukaani.org/lzma/

Re: not hardwiring gpg

[Jim Meyering]

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

[Jim Meyering]

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 two LZMA compressed targets?

 See http://lists.gnu.org/archive/html/lzip-bug/2008-11/msg3.html ,
 I think this should answer it.

But nothing I saw there mentioned the upcoming (and superior)
xz format/tool (aka lzma-utils' unstable branch).  That is what's on
the current head of the master branch of the lzma-utils git tree.

git://ctrl.tukaani.org/lzma-utils.git

xz is the name of the new tool as well as the corresponding suffix.
Lasse Collin says there may well be a beta release this year.

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 as there's a beta xz release (i.e., stable format),
I'll be switching from .lzma to .xz suffixes for all tarballs I create.

Re: lzip support

[Jim Meyering]

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 already had LZMA
 support, can someone please explain LZIP vs LZMA and why we now
 have at least two LZMA compressed targets?

 See http://lists.gnu.org/archive/html/lzip-bug/2008-11/msg3.html ,
 I think this should answer it.

But nothing I saw there mentioned the upcoming (and superior)
xz format/tool (aka lzma-utils' unstable branch).  That is what's on
the current head of the master branch of the lzma-utils git tree.

git://ctrl.tukaani.org/lzma-utils.git

xz is the name of the new tool as well as the corresponding suffix.
Lasse Collin says there may well be a beta release this year.

 Nothing has happened since at least July when I inquired. I mean, it is
 not that hard to add the two features, magic byte string and checksum,
 is it? (IMHO the format should have had these from the beginning even.)

Nothing has happened ?
Did you look at the code at all, or ask Lasse?

$ git log --since=2008-07-01 -p|diffstat|tail -1
 416 files changed, 14731 insertions(+), 13348 deletions(-)

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 as there's a beta xz release (i.e., stable format),
I'll be switching from .lzma to .xz suffixes for all tarballs I create.

 lzip is (marked as) stable now, it was enough waiting for lzma.

I see xz as the right format and tool, so prefer not to
encourage the use of any other new tool to do the same job.

Re: lzip support

[Jim Meyering]

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 as there's a beta xz release (i.e., stable format),
 I'll be switching from .lzma to .xz suffixes for all tarballs I create.

 Competition is good and even between open source projects.  However,
 since many free projects depend on Automake, it makes sense for
 Automake to channel the energy into a smaller set of preferred
 formats.  Note that formats may be independent from the tools which
 produce and consume them so that tools may still compete.  If new
 formats are added, the least worthy of the existing supported
 distribution formats should be deprecated and eventually removed. This
 means that if .xz is added that .lzma should be immediately deprecated
 and slated for retirement from Automake.  Do you agree with this
 philosophy?

Sure: once there is a beta release of xz, lzma can go.

When adding xz support, I considered whether to remove mention of lzma
from NEWS, since it's now slated for removal.  But of course, this is
just my opinion.  Ralf's is the one who matters here ;-)

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

[Jim Meyering]

I like automake's upcoming --silent-rules option enough
that I'm making it the default (when possible) for coreutils.
Since I bootstrap using automake from its next branch, it's
enabled for me.  And that translates to enhanced Makefile.in
files in the tarballs I generate.  The net result is that when
you run make (using distributed Makefile.in files), you'll
see something like this:

 ...
 CC  id.o
 CC  kill.o
 CC  operand2sig.o
 CC  logname.o
 CC  pathchk.o
 CC  printenv.o
 CC  printf.o
 CC  pwd.o
 CC  runcon.o
 CC  seq.o
 CC  sleep.o
 CC  tee.o
 CC  test.o
 CC  timeout.o
 CC  true.o
 CC  truncate.o
 CC  tty.o
 CC  whoami.o
 CC  yes.o
 CC  base64.o
 CC  setuidgid.o
 CC  getlimits.o
 CC  su.o
 AR  libver.a
 CCLD  uname
 CCLD  chroot
 CCLD  hostid
 CCLD  nice
 CCLD  df
 CCLD  pinky
 CCLD  users
 CCLD  uptime
 CCLD  stty
 CCLD  [
 CCLD  chcon
 CCLD  who
 CCLD  chgrp
 CCLD  chown
 CCLD  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 possible

* bootstrap: Use automake's --silent-rules option.
---
 bootstrap |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/bootstrap b/bootstrap
index 27e4ec2..e834a2b 100755
--- a/bootstrap
+++ b/bootstrap
@@ -686,6 +686,12 @@ find $m4_base $source_base \
   -depth \( -name '*.m4' -o -name '*.[ch]' \) \
   -type l -xtype l -delete  /dev/null 21

+# Use automake's --silent-rules option, if possible.
+automake=${AUTOMAKE-automake} --add-missing --copy --force-missing
+(${AUTOMAKE-automake} --help) 21 \
+| grep -e '^  *--silent-rules'  /dev/null \
+   automake=$automake --silent-rules
+
 # Reconfigure, getting other files.

 for command in \
@@ -693,7 +699,7 @@ for command in \
   ${ACLOCAL-aclocal} --force -I m4 \
   ${AUTOCONF-autoconf} --force \
   ${AUTOHEADER-autoheader} --force \
-  ${AUTOMAKE-automake} --add-missing --copy --force-missing
+  $automake
 do
   if test $command = libtool; then
 use_libtool=0
--
1.6.2.rc1.285.gc5f54

choosing the default for silent-rules

[Jim Meyering]

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 make V=0 behavior the default?
Of course, I can do this:

diff --git a/configure.ac b/configure.ac
index 8d9bcaf..37ffd05 100644
--- a/configure.ac
+++ b/configure.ac
@@ -34,6 +34,9 @@ AC_CONFIG_HEADERS([lib/config.h:lib/config.hin])

 AM_INIT_AUTOMAKE([1.10b dist-xz color-tests parallel-tests silent-rules])

+# I prefer --enable-silent-rules, so make that the default.
+test x$enable_silent_rules != xno  AM_DEFAULT_VERBOSITY=0
+
 AC_PROG_CC_STDC
 AM_PROG_CC_C_O
 AC_PROG_CPP

Perhaps give AM_SILENT_RULES a parameter?
Then I wouldn't have to use $enable_silent_rules and
AM_DEFAULT_VERBOSITY.

Re: choosing the default for silent-rules

[Jim Meyering]

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 is very important for some things,
but this is more like meta-compatibility, and that is valuable
only as long as it doesn't get in the way of progress.

Anyone who is sophisticated enough to be logging build output
for multiple packages should also be expecting to tweak their
build process to adapt to upstream changes.  This is just another
one of those changes.

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 broke their XYZ, I can always change it back.

 Is there a recommended way to make the make V=0 behavior the default?
 Of course, I can do this:
...
 Actually, you can do either of this:
...
 2)
   # remove `silent-rules' from AM_INIT_AUTOMAKE and add
   AM_SILENT_RULES([yes])

Thanks.  I'll use that.
I should have looked more carefully.

Re: choosing the default for silent-rules

[Jim Meyering]

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 broke their XYZ, I can always change it back.

 I'm a bit undecided on the issue, with no great preference.  Thus I
 think I'll keep the argument to AM_SILENT_RULES undocumented for now
 and let users fight this out when it spreads.

Fine by me.
Silence ru13z!
;-)

using color-tests backwards-portably

[Jim Meyering]

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 configure.ac-modifying solution,

https://www.redhat.com/archives/libguestfs/2009-August/msg00160.html

but it's too ugly.

Can you think of another way?

[I know I could roll my own via check.mk, like what coreutils
used prior to automake-1.11, but would rather use automake's own
support for those options, when possible. ]

Thanks,

Jim

Re: stable coreutils-8.1 today, fingers crossed

[Jim Meyering]

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 /usr /usr/src /usr/src/coreutils-8.1
 ...
  drwxrwxrwx 13 root root 4096 Nov 18 18:55 /usr/src/coreutils-8.1
 
  don't know why
 
  Just the side effect of using tar as root
  --no-same-permissions let umask be applied

 Thanks for explaining.
 That's another good reason to do less as root.

 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 of it as a LART for
anyone who builds from source as root  ;-)

I think the motivation was to avoid imposing restrictions.  With relaxed
permissions, the umask of the unpacker completely determines the permissions.
If the distribution-tarball-creator were to choose stricter permissions,
say prohibiting group/other write access, that would make it harder for
people who use 002 and want all directories to be group-writable.

That said, I'd have no objection to applying chmod 755
(rather than a+rwx) to the directories that go into the tarball.

FYI, those permissions were set via the Automake-generated make dist
rule, so every automake-using package has created distribution tarballs
that way for at least 10 years.

Re: permissions of files in dist tarball

[Jim Meyering]

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 of it as a LART for
 anyone who builds from source as root  ;-)

 I think the motivation was to avoid imposing restrictions.  With relaxed
 permissions, the umask of the unpacker completely determines the permissions.
 If the distribution-tarball-creator were to choose stricter permissions,
 say prohibiting group/other write access, that would make it harder for
 people who use 002 and want all directories to be group-writable.

 That said, I'd have no objection to applying chmod 755
 (rather than a+rwx) to the directories that go into the tarball.

 FYI, those permissions were set via the Automake-generated make dist
 rule, so every automake-using package has created distribution tarballs
 that way for at least 10 years.

 Automake is following the GNU Coding Standards recommendation here,
 which lists another reason ((standards.info)Releases):

  Make sure that the directory into which the distribution unpacks (as
   well as any subdirectories) are all world-writable (octal mode 777).
   This is so that old versions of `tar' which preserve the ownership and
   permissions of the files from the tar archive will be able to extract
   all the files even if the user is unprivileged.

  Make sure that all the files in the distribution are world-readable.

Thanks, Ralf.

Considering that that text is at least 10 years old, I think
we can say with confidence that the reason for it (that then-old
version of tar) is no longer relevant.  I would like to update
that part of the GNU Coding Standards.

Can anyone think of a reason *not* to revise the GCS to allow
or even recommend using more safety-conscious permissions?

Re: writability of directories in distributions

[Jim Meyering]

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 not 'root' is
 doing the unpacking.

 While there is something to be said for letting the package maintainer
 make this choice, there is also clearly something to be said for letting
 the recipient make the choice.

IMHO, avoiding confusion and risks when root (however unguided) untars
such an archive is more important.

 I suspect that leaving the current behavior alone will irritate some,
 and changing the current behavior will irritate others.

People who will be irritated by such a change should already
be accustomed to dealing with the non-777-perm directories from
numerous other sources.  Just a quick sampling: perl, git,
and the linux kernel have 0755 directories in their tarballs,
as well as at least a few of the tarballs I checked in the
BSD ports/distfiles/.

Re: writability of directories in distributions

[Jim Meyering]

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 issue, as I recall, has to do with whether or not 'root' is
 doing the unpacking.

 Remember that 'root' is going away on many systems which are now using
 roles' (or temporary powers) instead.

At whatever pace, this won't be widespread enough
to constitute a solution anytime soon.

 Extracting a tarball as 'root'
 is a dangerous thing to do since many things may be preserved which
 make no sense for the current system, or may even be dangerous.

 The only approach which makes real sense is if the extracted files and
 directories are give the UID/GID of the user/group extracting those

IMHO, that is beyond the scope of my proposal.
We cannot control what tools people use.
However, automake *can* limit the risk when people use
tools (like GNU tar) that exhibit the offending behavior.

 files (according to OS-specific rules), and that directories are given
 access permissions limited only by the current umask and OS-specific
 rules (as per mkdir(2)).  Much of this is based on behavior of the tar
 command used for the extraction.

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

[Jim Meyering]

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

 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)

# 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 \
  GPERF=false \
  LIBTOOL=false \
  MAKEINFO=false

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

[Jim Meyering]

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 point.  LIBTOOL is not like the others, since it *is*
required to be run when building from a distribution tarball.

 Adding LIBTOOL here is wrong; you meant LIBTOOLIZE.

I've removed it.
I don't see anything except bootstrap that runs $(LIBTOOLIZE).  Do you?

 There are several packages that would break, or at least have a less
 effective distcheck with this.  For example, Libtool uses Autoconf and
 Automake tools in its new testsuite.  Lots of packages build info files
 in the build tree only, or build HTML with makeinfo.

Sure.  This is policy.
That's why the variable is now overridable.

 Since currently the variable $(null_AM_MAKEFLAGS) isn't used in Automake
 code at all however, did you mean to move more code there?

 # Use this to make sure we don't run these programs when building
 # from a virgin tgz file, below.
 null_AM_MAKEFLAGS ?= \

It's used in a coreutils' own make distcheck addition,
from dist-check.mk:

ALL_RECURSIVE_TARGETS += my-distcheck
my-distcheck: $(DIST_ARCHIVES) $(local-check)
$(MAKE) syntax-check
$(MAKE) check
-rm -rf $(t)
mkdir -p $(t)
$(amtar_extract_) $(preferred_tarball_) -C $(t)
(set -e; cd $(t)/$(distdir);\
  ./configure --quiet --enable-gcc-warnings --disable-nls; \
  $(MAKE) AM_MAKEFLAGS='$(null_AM_MAKEFLAGS)';  \
  $(MAKE) dvi;  \
  $(install-transform-check);   \
  $(my-instcheck);  \
  $(coreutils-path-check);  \
  $(MAKE) distclean \
)
...

Re: dist-xz compression level

[Jim Meyering]

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

Re: dist-xz compression level

[Jim Meyering]

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 it possible to setup this to be the default inside makefiles?
 (I use make dist only for the final release...)

Sure.
Create a GNUmakefile containing

  export XZ_OPT=-9ev

and just passing all other rules to the default Makefile.

Re: absolute build directory with spaces

[Jim Meyering]

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/test-vc-list-files-git.sh
 @@ -17,7 +17,7 @@
  # along with this program.  If not, see http://www.gnu.org/licenses/.  */

  : ${srcdir=.}
 -. $srcdir/init.sh; path_prepend_ $abs_aux_dir .
 +. $srcdir/init.sh; path_prepend_ $abs_aux_dir .

 This extra check, part of make distcheck, that verifies that the package
 builds even when the srcdir or builddir contains a space, would be useful
 for more packages. On mingw, it is frequent to have spaces in directories.

It would be useful for builddir, but not for srcdir.
That srcdir is sane is already guaranteed via every
reasonably-modern autoconf-generated configure script.

 Could Automake offer this check, if a certain Automake option is specified
 in AM_INIT_AUTOMAKE?

I'd like that.
Then I'd use it in all automake-using projects,
and not just in the few that have this custom check[*].

But note that as I've implemented it for coreutils, this
is rather expensive, in that it requires an additional, full
non-srcdir build-and-make-check from tarball (sole difference is
that the absolute builddir has a component named a b).
It has to be non-srcdir, since the srcdir cannot be the
invalid like the builddir can.

However, if this build-and-make-check passes, there is little
reason to repeat the process with a normal builddir, so there
is no inherent requirement that it take more time.

--
[*] It's the taint-distcheck rule here:
http://git.sv.gnu.org/cgit/coreutils.git/tree/dist-check.mk#n49

Re: absolute build directory with spaces

[Jim Meyering]

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 dir name.
  ...
  --- a/tests/test-vc-list-files-git.sh
  +++ b/tests/test-vc-list-files-git.sh
  @@ -17,7 +17,7 @@
 
   # along with this program.  If not, see
   http://www.gnu.org/licenses/.  */
 
   : ${srcdir=.}
 
  -. $srcdir/init.sh; path_prepend_ $abs_aux_dir .
  +. $srcdir/init.sh; path_prepend_ $abs_aux_dir .

 This extra check, part of make distcheck, that verifies that the
 package builds even when the srcdir or builddir contains a space,
 would be useful for more packages. On mingw, it is frequent to
 have spaces in directories.

 Could Automake offer this check, if a certain Automake option is
 specified in AM_INIT_AUTOMAKE?
 What about instead making the names of the temporaries source/build/install
 directories used by make distcheck configurable?  This will offer more
 flexibility, and won't introduce still another automake option which would
 make backward-compatibility more problematic.

 I was thinking of something on these lines:

   $ cat Makefile.am
   ...
   AM_DISTCHECK_BUILDDIR_NAME = _ b u i l d ## will be relative to $(distdir)
   AM_DISTCHECK_SRCDIR_NAME = . ## likewise
   AM_DISTCHECK_INSTALLDIR_NAME = i...@l1   ## likewise

 If you like the proposal, I might try to implement this (but right away).

I do like it.  Thanks!

Re: [coreutils] debbugs

[Jim Meyering]

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 be worked with email only, right?

Yes, that was a big selling point for me.

 Automake has its Gnats, mostly unused and feature-poor, I don't like it
 much, and with Libtool, we've never been able to consistently use a bug
 tracker, either.  The Savannah bug/patch tracker require lots of
 clicking and waiting for web scripts to ponder, that's not so much fun.

 Also, the number of unresolved bugs in autotools packages tends to
 infinity in the long run (not monotonically, but let's be honest, there
 are always more issues than we can address, be they bugs in the
 autotools themselves or in the way users use them, or in third-party
 packages).

 With that in mind, I'm looking for something that can keep things in
 order in some way, be that things added by users or ourselves.
 Who do we talk to if we want to try it out?

Glenn Morris is the guy.  He set up the emacs one and then made it so
that with almost no work we could use it for coreutils, too.

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

[Jim Meyering]

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

[Jim Meyering]

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 into this soonish.  Could you please
 open a bug report on bug-automake so that I won't forget about
 the issue?

Sure.  I did that via http://debbugs.gnu.org/8621

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

[Jim Meyering]

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.

 On this platform, we have both gcc and a native cc compiler. While gcc
 handles the combination of the -c and -o arguments, our native cc
 compiler does not. Thus, the coreutils configure script sets
 ac_cv_prog_gcc_cc_c_o=no. This leads to using the build-aux/compile
 script, which in turn leads to the following interesting result
 (edited for clarity):

   CC   version.o
   AR   libver.a
   CC   cp.o
   CC   copy.o  (point 1)
   CC   cp-hash.o
   CC   extent-scan.o
   CCLD cp.pm
   CC   ginstall-install.o
   CC   ginstall-prog-fprintf.o
   CC   ginstall-copy.o  (point 2)
   CC   ginstall-cp-hash.o
   CC   ginstall-extent-scan.o
   CCLD ginstall.pm
   CC   mv.o
   CC   remove.o
   CCLD mv.pm
 gcc: copy.o: No such file or directory.
 gcc: cp-hash.o: No such file or directory.
 gcc: extent-scan.o: No such file or directory.
 make[3]: *** [mv.pm] Error 1

 The root cause of this failure is as follows. The same issue affects
 copy.o, cp-hash.o and extent-scan.o, but I'll just focus on copy.o.

 At point 1, the build-aux/compile runs gcc (w/o -o) to produce copy.o.
 At point 2, the script produces copy.o again, then renames it to
 ginstall-copy.o, thereby deleting copy.o.

 The src/Makefile does not list copy.o as a dependency of mv.pm (Oops),
 so Make does not rebuild copy.o prior to running the link command.

My src/Makefile and src/Makefile.in do include that dependency,
assuming your EXEEXT is .pm.
Does your version of that file look different from this?

am__objects_1 = copy.$(OBJEXT) cp-hash.$(OBJEXT) extent-scan.$(OBJEXT)
am_mv_OBJECTS = mv.$(OBJEXT) remove.$(OBJEXT) $(am__objects_1)
mv_OBJECTS = $(am_mv_OBJECTS)
...
mv$(EXEEXT): $(mv_OBJECTS) $(mv_DEPENDENCIES) $(EXTRA_mv_DEPENDENCIES)

This is not due to a missing dependency,
but rather that the compile script removes copy.o
in the process of creating ginstall-copy.o.
You can see that by the fact that when you rerun make
after the above failure, it does regenerate copy.o.

 Hence, the linker (gcc) complains that it cannot find the file.

 On a platform where both cc and $CC handle the combination of -c and -o
 correctly, this issue cannot arise.

 The solution is either to make the compile script smarter, or to have
 the dependencies of mv.pm properly listed, or to have mv.pm depend upon
 a renamed copy of copy.o, much as is done for ginstall, or to set the
 environment variable ac_cv_prog_cc_gcc_c_o=yes before running configure.
 This last technique presumes that the faulty cc compiler is never
 actually used, which seems to be the case here.

 Speaking as someone who is fairly familiar with bash, make, and
 autoconf, this was still took a lot longer to figure out that I'd like
 to admit.  I believe that I have correctly explained the issue, but I
 apologize if there are errors in the above description.

 I suspect that you can reproduce this issue by forcing
 ac_cv_prog_cc_gcc_c_o=no and then running configure.

Running this,
  ac_cv_prog_cc_gcc_c_o=no ./configure  make
I was indeed able to reproduce it.

I think you're right that making compile smarter is the way to go.
It looks like it could be modified to link (or copy) the source file
to some temporary file name, e.g., copy-xYV4aP.c, compile that
to copy-xYV4aP.o, and rename the latter to the destination .o file.
Of course, it would have to remove the temporary file upon termination--
both irregular and normal.

This would also resolve the parallel build race whereby two or more
programs using the same object file both compile the same source to
the same object and rename that file to a different destination.

To the automake folks, is there any reason not to do that?

Re: [RFC] Releasing automake 1.11.2

[Jim Meyering]

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 the users for the
 backward-incompatible changes planned for automake 1.12 (so, the
 more 1.11.2 precedes 1.12, the more these warnings will have a
 chance to be effective).

Hi Stefano,

I agree that this is a good time to make a new release.

 Ralf, Jim, could we agree on a timeline/plan of sort for the release
 of automake 1.11.2?  I've never done nor witnessed as an insider
 an automake release, so I'd rather leave someone else take the lead
 on this; but I'll try to contribute and learn as much as I can of
 course ;-)

I'd rather... ;-)
But this seems like the perfect time to start.

I suggest that you start off by generating a GPG key (of type RSA, not
DSA, and at least 2048 bits long), and upload it to your Savannah
profile, and eventually to public key servers.

[If you're new to GPG, please learn about key security practices,
 before you generate the key you end up using.  Most How to generate
 a GPG key references I found are outdated, but this one looks good:
 http://fedoraproject.org/wiki/Creating_GPG_Keys
 ]

Then you'll want to register your GPG key for upload of automake
tarballs, per the instructions in the maintainers guide:

  https://www.gnu.org/prep/maintain/html_node/Automated-Upload-Registration.html

Re: [RFC] Releasing automake 1.11.2

[Jim Meyering]

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 bugs
 on exotic platforms before the stable release.

 Since the current version number for automake in branch-1.11 is `1.11.1a',
 I *think* that running `make git-release' from a freshly bootstrapped
 branch-1.11 (all while following the directions given in the HACKING file,
 obviously) should be enough to create *and release* the beta.   But I'd
 rather be sure and reassured about this, to avoid the risk of messing up
 my first release; so, at risk of looking dumb, I'm asking here for an
 ACK from either Jim or Ralf before proceeding.

Hi Stefano,

Using HACKING as your guide appears to be the right thing,
but I can't be as reassuring as Ralf, since I've never made
an automake release.

Re: GNU Automake 1.12.1 released

[Jim Meyering]

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 in Gentoo in many packages.

 https://bugs.gentoo.org/show_bug.cgi?id=automake-1.12

 mkdir_p is gone in automake-1.12.1 for what we're concerned — I also
 listed it in the 1.12 instead of planned for 1.13 in my own guide
 http://goo.gl/bda6l as I thought it was intentional.

 Ouch, I can reproduce this :-/  The issue is that the call to
 AM_PROG_MKDIR_P in AM_INIT_AUTOMAKE has been substituted by a
 call to AC_PROG_MKDIR_P, which doesn't define $(mkdir_p).  This
 was an unintended regression.

 I will soon push the attached patches to take care of the problem.
 Note that they only re-introduce the $(mkdir_p) variable (because
 is very easy to do so), but not the @mkdir_p@ substitution.  Anyone
 knows if this can create problems in practice?

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. For these automake versions,
  # @install_sh@ does not start with $(SHELL), so we add it.
  # In automake = 1.10, @mkdir_p@ is derived from ${MKDIR_P}, which is defined
  # either as /path/to/mkdir -p or .../install-sh -c -d. For these automake
  # versions, $(mkinstalldirs) and $(install_sh) are unused.
  mkinstalldirs = $(SHELL) @install_sh@ -d
  install_sh = $(SHELL) @install_sh@
  MKDIR_P = @MKDIR_P@
  mkdir_p = @mkdir_p@

Since that file is copied into many projects,
I'd recommend to substitute @mkdir_p@, as well.

Re: GNU Automake 1.12.1 released

[Jim Meyering]

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. For these automake versions,
   # @install_sh@ does not start with $(SHELL), so we add it.
   # In automake = 1.10, @mkdir_p@ is derived from ${MKDIR_P}, which is 
 defined
   # either as /path/to/mkdir -p or .../install-sh -c -d. For these 
 automake
   # versions, $(mkinstalldirs) and $(install_sh) are unused.
   mkinstalldirs = $(SHELL) @install_sh@ -d
   install_sh = $(SHELL) @install_sh@
   MKDIR_P = @MKDIR_P@
   mkdir_p = @mkdir_p@

 Since that file is copied into many projects,
 I'd recommend to substitute @mkdir_p@, as well.

 That is simply enough to do if we content ourselves with a substitution
 that makes it usable in Makefiles only:

 AC_SUBST([mkdir_p], ['$(MKDIR_P)'])

 See attached patch.  OK?

Thanks.  That patch looks fine, applied and passed make check.
One wording nit below.

 Subject: [PATCH] compat: automake should substitute @mkdir_p@, for backward
  compatibility

 That has been unwittingly broken by commit v1.12-19-g7a1eb9f of 2012-04-28,
 AM_PROG_MKDIR_P: deprecate, to be removed in Automake 1.13. We thought it
 wasn't a big deal, but Jim Meyering reported that @mkdir_p@ is used in
 gettext's Makefile.in.in template:
 http://lists.gnu.org/archive/html/automake/2012-07/msg00014.html

 * lib/am/header-vars.am (mkdir_p): Don't define.
 * m4/init.m4 (AM_INIT_AUTOMAKE): AC_SUBST 'mkdir_p' with $(MKDIR_P).
 * t/mkdir_p.sh, t/mkdirp-deprecation.sh: Enhance.
 * NEWS: Update.

 Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
 ---
  NEWS|8 
  lib/am/header-vars.am   |5 -
  m4/init.m4  |5 +
  t/mkdir_p.sh|   12 
  t/mkdirp-deprecation.sh |   12 
  5 files changed, 25 insertions(+), 17 deletions(-)

 diff --git a/NEWS b/NEWS
 index d38554d..eaab9d1 100644
 --- a/NEWS
 +++ b/NEWS
 @@ -6,10 +6,10 @@ New in 1.12.2:
  long-deprecated 'configure.in' name for the Autoconf input file.
  You are advised to use the recommended name 'configure.ac' instead.

 -  - 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) should still remain available for the moment
 -though.
 +  - The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
 +be removed in Automake 1.13.  The $(mkdir_p) make variable and the
 +@mkdir_p@ substitution should still remain available (as aliases of

should can imply doubt.  There is none.

s/should still/will/

 +$(MKDIR_P)) for the moment, for better backward compatibility.

- Autoconf 2.65 or later will be required by the next major Automake
  version (1.13).  Until now, Automake has required Autoconf version

Re: GNU Automake 1.12.1 released

[Jim Meyering]

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) should still remain available for the moment
 -though.
 +  - The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
 +be removed in Automake 1.13.  The $(mkdir_p) make variable and the
 +@mkdir_p@ substitution should still remain available (as aliases of

 should can imply doubt.  There is none.

 s/should still/will/

 OK, consider this fixed.

 And consider the below squashed in:

   diff --git a/NEWS b/NEWS
   index eaab9d1..faf10c9 100644
   --- a/NEWS
   +++ b/NEWS
   @@ -107,13 +107,9 @@ Bugs fixed in 1.12.2:

* Bugs introduced by 1.12.1:

   -  - Automake generated Makefiles define once again the $(mkdir_p) make
   -variable (simple ans an alias for $(MKDIR_P)), for better backward
   -compatibility.  The '@mkdir_p@' substitution is however not enabled
   -by default anymore; anyone needing it should call the AM_PROG_MKDIR
   -m4 macro explicitly (beware that this macro has been deprecated since
   -the previous Automake release 1.12.1, and will be removed in Automake
   -1.13).
   +  - Automake provides once again the '$(mkdir_p)' make variable and the
   +'@mkdir_p@' substitution (both as simple aliased for '$(MKDIR_P)'),

s/aliased/aliases/

   +for better backward-compatibility.

 Regards,
   Stefano

parallel make check output lines are lost!?!

[Jim Meyering]

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 case there were
any differences.  Imagine my surprise when I found numerous differences
showing that lines (mostly PASS: test-name ones) are omitted from
the output.

I used this command to compare the log from the 2nd run
to each the 12 following ones.  Output below:

for i in $(seq 3 15); do diff-sorted makerr-2 makerr-$i; done

Note that the summary lines (including PASS:... counts) were
always the same.

Is this a known problem?


--- makerr-22012-08-01 16:40:00.110496149 +0200
+++ makerr-32012-08-01 16:40:00.113496009 +0200
@@ -58,6 +58,7 @@
 PASS: cp/nfs-removal-race
 PASS: cp/no-deref-link1
 PASS: cp/no-deref-link2
+PASS: cp/no-deref-link3
 PASS: cp/parent-perm
 PASS: cp/parent-perm-race
 PASS: cp/preserve-2
@@ -361,7 +362,6 @@
 PASS: readlink/can-f
 PASS: readlink/can-m
 PASS: readlink/rl-1
-PASS: rm/cycle
 PASS: rm/dangling-symlink
 PASS: rm/deep-1
 PASS: rm/deep-2
--- makerr-22012-08-01 16:40:00.125495449 +0200
+++ makerr-42012-08-01 16:40:00.128495311 +0200
@@ -58,6 +58,7 @@
 PASS: cp/nfs-removal-race
 PASS: cp/no-deref-link1
 PASS: cp/no-deref-link2
+PASS: cp/no-deref-link3
 PASS: cp/parent-perm
 PASS: cp/parent-perm-race
 PASS: cp/preserve-2
@@ -103,7 +104,6 @@
 PASS: du/files0-from
 PASS: du/files0-from-dir
 PASS: du/hard-link
-PASS: du/inacc-dest
 PASS: du/inacc-dir
 PASS: du/inaccessible-cwd
 PASS: du/long-from-unreadable
@@ -332,7 +332,6 @@
 PASS: mv/hard-3
 PASS: mv/hard-4
 PASS: mv/hard-link-1
-PASS: mv/hard-verbose
 PASS: mv/i-1
 PASS: mv/i-2
 PASS: mv/i-4
@@ -351,7 +350,6 @@
 PASS: mv/part-symlink
 PASS: mv/partition-perm
 PASS: mv/perm-1
-PASS: mv/symlink-onto-hardlink
 PASS: mv/symlink-onto-hardlink-to-self
 PASS: mv/to-symlink
 PASS: mv/trailing-slash
@@ -364,7 +362,6 @@
 PASS: rm/cycle
 PASS: rm/dangling-symlink
 PASS: rm/deep-1
-PASS: rm/deep-2
 PASS: rm/dir-no-w
 PASS: rm/dir-nonrecur
 PASS: rm/dot-rel
--- makerr-22012-08-01 16:40:00.140494751 +0200
+++ makerr-52012-08-01 16:40:00.143494613 +0200
@@ -58,6 +58,7 @@
 PASS: cp/nfs-removal-race
 PASS: cp/no-deref-link1
 PASS: cp/no-deref-link2
+PASS: cp/no-deref-link3
 PASS: cp/parent-perm
 PASS: cp/parent-perm-race
 PASS: cp/preserve-2
@@ -495,7 +496,6 @@
 SKIP: tail-2/inotify-rotate
 SKIP: touch/now-owned-by-other
 Testsuite summary for GNU coreutils 8.17.56-f24bf-dirty
-append-only: skipped test: must be run as root
 arch: skipped test: required program(s) not built
 assert-2: skipped test: very expensive: disabled by default
 assert: skipped test: very expensive: disabled by default
@@ -536,11 +536,9 @@
 nice: skipped test: this test must be run at nice level 0
 no-give-up: skipped test: must be run as root
 now-owned-by-other: skipped test: must be run as root
-one-file-system: skipped test: must be run as root
 perm: skipped test: very expensive: disabled by default
 preserve-gid: skipped test: must be run as root
 problematic-chars: skipped test: must be run as root
-read-only: skipped test: must be run as root
 selinux: skipped test: must be run as root
 skip-seek-past-dev: skipped test: must be run as root
 sort-benchmark-random: skipped test: very expensive: disabled by default
--- makerr-22012-08-01 16:40:00.155494051 +0200
+++ makerr-62012-08-01 16:40:00.158493913 +0200
@@ -55,9 +55,9 @@
 PASS: cp/link-no-deref
 PASS: cp/link-preserve
 PASS: cp/link-symlink
-PASS: cp/nfs-removal-race
 PASS: cp/no-deref-link1
 PASS: cp/no-deref-link2
+PASS: cp/no-deref-link3
 PASS: cp/parent-perm
 PASS: cp/parent-perm-race
 PASS: cp/preserve-2
@@ -370,7 +370,6 @@
 PASS: rm/dot-rel
 PASS: rm/empty-inacc
 PASS: rm/empty-name
-PASS: rm/f-1
 PASS: rm/fail-eacces
 PASS: rm/fail-eperm
 PASS: rm/i-1
--- makerr-22012-08-01 16:40:00.170493353 +0200
+++ makerr-72012-08-01 16:40:00.173493213 +0200
@@ -58,6 +58,7 @@
 PASS: cp/nfs-removal-race
 PASS: cp/no-deref-link1
 PASS: cp/no-deref-link2
+PASS: cp/no-deref-link3
 PASS: cp/parent-perm
 PASS: cp/parent-perm-race
 PASS: cp/preserve-2
--- makerr-22012-08-01 16:40:00.185492654 +0200
+++ makerr-82012-08-01 16:40:00.188492514 +0200
@@ -58,6 +58,7 @@
 PASS: cp/nfs-removal-race
 PASS: cp/no-deref-link1
 PASS: cp/no-deref-link2
+PASS: cp/no-deref-link3
 PASS: cp/parent-perm
 PASS: cp/parent-perm-race
 PASS: cp/preserve-2
@@ -165,7 +166,6 @@
 PASS: ls/stat-free-symlinks
 PASS: ls/stat-vs-dirent
 PASS: ls/symlink-slash
-PASS: ls/time-style-diag
 PASS: ls/x-option
 PASS: misc/base64
 PASS: misc/basename
@@ -282,7 +282,6 @@
 PASS: misc/tee-dash
 PASS: misc/test
 PASS: misc/test-diag
-PASS: misc/timeout
 PASS: misc/timeout-group
 PASS: misc/timeout-parameters
 PASS: misc/tr
--- makerr-22012-08-01 16:40:00.199492001 +0200
+++ makerr-92012-08-01 

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

[Jim Meyering]

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 \
   RUN_EXPENSIVE_TESTS=no  makerr-$i

 ... and output redirection.  Bad combination; take a look at:

   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11413#8

 So, if this is to be considered a bug, it is a make bug, not an
 Automake one IMHO.  To verify that this is the case you might want
 to re-try your 100 runs above with this slight change:

for i in $(seq 100); do
   +   :  makerr-$i
   make -j25 check -C tests VERBOSE=yes \
 RUN_EXPENSIVE_TESTS=no  makerr-$i \
t=. || t=X
   printf $t
done

 and verify that in this case all the 'makerr-*' files are indeed equal.

Hi Stefano,

Thanks for the pointer.  I knew that rang a bell.
For the record, to avoid the problem one must append to the existing log file:

 for i in $(seq 100); do
+   :  makerr-$i
make -j25 check -C tests VERBOSE=yes \
- RUN_EXPENSIVE_TESTS=no  makerr-$i \
+ RUN_EXPENSIVE_TESTS=no  makerr-$i \
 t=. || t=X
printf $t
 done

latest automake makes emacs bootstrap fail

[Jim Meyering]

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 automake's newer missing script
into my cloned emacs build tree, and with that the emacs bootstrap
now succeeds.

Jim

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

[Jim Meyering]

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   libvirtmod_la-typewrappers.lo
  CC   libvirtmod_la-libvirt.lo
  CC   libvirtmod_qemu_la-libvirt-qemu-override.lo
  CC   libvirtmod_qemu_la-typewrappers.lo
  CC   libvirtmod_qemu_la-libvirt-qemu.lo
  CCLD libvirtmod_qemu.la
  CCLD libvirtmod.la
make[3]: Leaving directory `/h/j/w/co/libvirt/python'
Making all in tests
make[3]: Entering directory `/h/j/w/co/libvirt/python/tests'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/h/j/w/co/libvirt/python/tests'
make[2]: Leaving directory `/h/j/w/co/libvirt/python'
Making all in tests
make[2]: Entering directory `/h/j/w/co/libvirt/tests'
Makefile:4355: *** Malformed target-specific variable definition.  Stop.
make[2]: Leaving directory `/h/j/w/co/libvirt/tests'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/h/j/w/co/libvirt'
make: *** [all] Error 2

That is because of this automake-generated rule:

undefine.log: undefine
@p='undefine'; \
b='undefine'; \
$(am__check_pre) $(LOG_DRIVER) --test-name $$f \
--log-file $$b.log --trs-file $$b.trs \
$(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) 
$(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) \
$$tst $(AM_TESTS_FD_REDIRECT)

The trouble is that undefine is an operator in GNU make.
Here's that part of GNU make's documentation:

6.9 Undefining Variables


If you want to clear a variable, setting its value to empty is usually
sufficient. Expanding such a variable will yield the same result (empty
string) regardless of whether it was set or not. However, if you are
using the `flavor' (*note Flavor Function::) and `origin' (*note Origin
Function::) functions, there is a difference between a variable that
was never set and a variable with an empty value.  In such situations
you may want to use the `undefine' directive to make a variable appear
as if it was never set. For example:

 foo := foo
 bar = bar

 undefine foo
 undefine bar

 $(info $(origin foo))
 $(info $(flavor bar))

   This example will print undefined for both variables.

   If you want to undefine a command-line variable definition, you can
use the `override' directive together with `undefine', similar to how
this is done for variable definitions:

 override undefine CFLAGS

The most pragmatic work-around is to rename the undefine test script.
However, Stephano, as automake maintainer, I think you will want to
fix automake not to prohibit the use of such test names.

AM_PROG_MKDIR_P: too soon to obsolete this macro?

[Jim Meyering]

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
configure.ac:477: warning: AM_PROG_MKDIR_P is m4_require'd but not 
m4_defun'd
m4/po.m4:23: AM_PO_SUBDIRS is expanded from...
m4/gettext.m4:57: AM_GNU_GETTEXT is expanded from...
configure.ac:477: the top level

That is because AM_PROG_MKDIR_P is marked to become obsolete
in the next release of automake.

I would have noticed sooner, but a few months ago, I worked
around this by installing a private fix in the --prefix=/p hierarchy
where I install personal copies of tools like this, then forgot to
report it.  Today I built using the latest automake on a new system
(without that manual patch) and re-diagnosed the problem.

$ cat /p/share/aclocal-1.12a/mkdirp.m4
##  -*- Autoconf -*-
# Copyright (C) 2003-2012 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.

# serial 2

# AM_PROG_MKDIR_P
# ---
# Check for 'mkdir -p'.
AC_DEFUN([AM_PROG_MKDIR_P],
[AC_PREREQ([2.60])dnl
AC_REQUIRE([AC_PROG_MKDIR_P])dnl
dnl Automake 1.8 to 1.9.6 used to define mkdir_p.  We now use MKDIR_P,
dnl while keeping a definition of mkdir_p for backward compatibility.
dnl @MKDIR_P@ is magic: AC_OUTPUT adjusts its value for each Makefile.
dnl However we cannot define mkdir_p as $(MKDIR_P) for the sake of
dnl Makefile.ins that do not define MKDIR_P, so we do our own
dnl adjustment using top_builddir (which is defined more often than
dnl MKDIR_P).
AC_SUBST([mkdir_p], [$MKDIR_P])dnl
case $mkdir_p in
  [[\\/$]]* | ?:[[\\/]]*) ;;
  */*) mkdir_p=\$(top_builddir)/$mkdir_p ;;
esac
])

Re: AM_PROG_MKDIR_P: too soon to obsolete this macro?

[Jim Meyering]

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:

   http://lists.gnu.org/archive/html/bug-gettext/2012-04/msg00018.html

 and other peoples have reported the problem as well:

   http://lists.gnu.org/archive/html/bug-gettext/2012-06/msg00012.html

 but no answer/feedback has come.

 If gettext doesn't fix the issue, projects using it will have to put a
 workaround in place themselves, like adding an AM_PROG_MKDIR_P definition
 (simply as an alias to AC_PROG_MKDIR_P) in a local '.m4' file.  Sorry.

Even if gettext fixes it today, it will take months, if not years
for the new version to reach developers.  Are you sure you want to
force every automake-and-gettext-using project to adapt to what looks
like a whim?

Please reconsider.

Re: AM_PROG_MKDIR_P: too soon to obsolete this macro?

[Jim Meyering]

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.  I sent a patch several months ago to gettext to fix that issue:

   http://lists.gnu.org/archive/html/bug-gettext/2012-04/msg00018.html

 and other peoples have reported the problem as well:

   http://lists.gnu.org/archive/html/bug-gettext/2012-06/msg00012.html

 but no answer/feedback has come.

 If gettext doesn't fix the issue, projects using it will have to put a
 workaround in place themselves, like adding an AM_PROG_MKDIR_P definition
 (simply as an alias to AC_PROG_MKDIR_P) in a local '.m4' file.  Sorry.

 Even if gettext fixes it today, it will take months, if not years
 for the new version to reach developers.

 That's why I sent the patch to gettext months ago, sigh :-(

 Are you sure you want to force every automake-and-gettext-using project
 to adapt to what looks like a whim?

 Please reconsider.

 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.

Thank you.  I will make time to prepare the patch.

FYI: update copyright dates for 2017

[Jim Meyering]

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 \
 update-copyright $(git ls-files)

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

[Jim Meyering]

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 any .el file not in the current
>> directory.
>
> In general, Emacs expects .el and .elc to be found in the same
> directory. Not adhering to this convention will likely break various
> Emacs features. Is this really something automake needs to enable at all?

An alternative would be to copy-or-link the .el file into the
destination directory. Indeed. That would work without breaking pre-23
emacs, so I will adjust my automake patch before pushing it to master.

Thanks.

However, please do consider undoing that breaking change before the
next emacs release, so we have a chance to release a fixed version of
automake before you remove the functionality being used in all
existing Makefile.in files.

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

[Jim Meyering]

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-dest-file function was removed, and that removal broke
>>> automake's elisp-compiling rule for any .el file not in the current
>>> directory.
>>
>> In general, Emacs expects .el and .elc to be found in the same
>> directory. Not adhering to this convention will likely break various
>> Emacs features. Is this really something automake needs to enable at all?
>
> An alternative would be to copy-or-link the .el file into the
> destination directory. Indeed. That would work without breaking pre-23
> emacs, so I will adjust my automake patch before pushing it to master.

Hi Glenn,

I've thought about this some more and do not like the idea of
requiring automake's elisp-compilation rule to make a copy of the
source file in the destination directory in this slightly contrived
case. 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 not have copies of the sources.
Installation processes will continue to copy both .el and .elc files
into place.

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

[Jim Meyering]

I was dismayed to discover this patch I wrote over three years ago.
Today I confirmed that the problem still remains by running these commands:

  git clone git://git.sv.gnu.org/hello.git \
cd hello && ./bootstrap && ./configure && env make dist

It failed like this:

  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" did not depend on $(BUILT_SOURCES)

* lib/am/distdir.am (distdir-am): New intermediate target.
Interpose this target between $(distdir) and its dependency
on $(DISTFILES), so that we can ensure $(BUILT_SOURCES) are
all created before we begin creating $(DISTFILES).
* t/dist-vs-built-sources.sh: Test for this.
* t/list-of-tests.mk (handwritten_TESTS): Add it.
* NEWS (Bugs fixed): Mention it.
Assaf Gordon reported that "make dist" (after ./configure
from a pristine clone of GNU hello) would fail due to the
absence of configmake.h while compiling lib/localcharset.c.
https://lists.gnu.org/r/bug-hello/2014-03/msg00016.html
---
 NEWS   |  3 +++
 lib/am/distdir.am  |  7 --
 t/dist-vs-built-sources.sh | 56 ++
 t/list-of-tests.mk |  1 +
 4 files changed, 65 insertions(+), 2 deletions(-)
 create mode 100644 t/dist-vs-built-sources.sh

diff --git a/NEWS b/NEWS
index dd057b7b1..7d52aeb93 100644
--- a/NEWS
+++ b/NEWS
@@ -113,6 +113,9 @@ New in ?.?.?:
   - Installed 'aclocal' m4 macros can now accept installation directories
 containing '@' characters (automake bug#20903)

+  - "./configure && make dist" no longer fails when a distributed file depends
+on one from BUILT_SOURCES.
+
   - When combining AC_LIBOBJ or AC_FUNC_ALLOCA with the
 "--disable-dependency-tracking" configure option in an out of source
 build, the build sub-directory defined by AC_CONFIG_LIBOBJ_DIR is now
diff --git a/lib/am/distdir.am b/lib/am/distdir.am
index 653966f0e..4b6543591 100644
--- a/lib/am/distdir.am
+++ b/lib/am/distdir.am
@@ -72,10 +72,13 @@ endif %?SUBDIRS%

 .PHONY: distdir
 if %?SUBDIRS%
-AM_RECURSIVE_TARGETS += distdir
+AM_RECURSIVE_TARGETS += distdir distdir-am
 endif %?SUBDIRS%

-distdir: $(DISTFILES)
+distdir: $(BUILT_SOURCES)
+   $(MAKE) $(AM_MAKEFLAGS) distdir-am
+
+distdir-am: $(DISTFILES)
 ##
 ## For Gnits users, this is pretty handy.  Look at 15 lines
 ## in case some explanatory text is desirable.
diff --git a/t/dist-vs-built-sources.sh b/t/dist-vs-built-sources.sh
new file mode 100644
index 0..94f8b600f
--- /dev/null
+++ b/t/dist-vs-built-sources.sh
@@ -0,0 +1,56 @@
+#! /bin/sh
+# Copyright (C) 2017 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+# Ensure that "make dist" no longer fails when a distributed file
+# depends on a file from the list of BUILT_SOURCES.
+
+. test-init.sh
+
+cat >> configure.ac << 'END'
+AC_PROG_CC
+AC_OUTPUT
+END
+
+cat > Makefile.am << 'END'
+BUILT_SOURCES = h.h
+h.h:
+   rm -f $@ $@-t
+   printf '%s\n' '#define F "F"' > $@-t
+   mv -f $@-t $@
+CLEANFILES = h.h
+
+EXTRA_DIST = gen
+gen: foo
+   ./foo > $@-t && mv $@-t $@
+
+bin_PROGRAMS = foo
+foo_SOURCES = foo.c
+END
+
+cat > foo.c << 'END'
+#include "h.h"
+int main (void) { printf ("%s\n", F); return 0; }
+END
+chmod a-w foo.c
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE
+
+./configure
+$MAKE dist
+
+:
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 33e5adc49..fde769971 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -409,6 +409,7 @@ t/dist-missing-m4.sh \
 t/dist-readonly.sh \
 t/dist-repeated.sh \
 t/dist-pr109765.sh \
+t/dist-vs-built-sources.sh \
 t/distcleancheck.sh \
 t/distcom2.sh \
 t/distcom3.sh \
--
2.14.1.729.g59c0ea183

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

[Jim Meyering]

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, but was blocked because
>>> its "make distcheck" would fail. That was because it distributes
>>> and builds from an elisp file, and automake's elisp-compilation
>>> rule uses a function that was marked obsolete back in 2009.
>>> Upstream Emacs finally removed support for that function in May,
>>> so anyone using emacs built since then will see the same failure
>>> I saw. It also strikes whenever building from a read-only source
>>> directory.
>>>
>>> This change switches the build command to use the "new" way.
>>>
>>> I started discussion on emacs-devel last night:
>>> https://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 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 any .el file not in the current
>>> directory.  In emacs-23.1 (July 2009) byte-compile-dest-file-function
>>> became the recommended way to adjust the byte-compiler's destination.
>>> * lib/am/lisp.am (.el.elc): Use byte-compile-dest-file-function,
>>> rather than byte-compile-dest-file.
>>> * t/lisp-readonly-srcdir.sh: New file, to test for the above.
>>> * t/list-of-tests.mk (handwritten_TESTS): Add it.
>>
>> Pushed to the micro branch:
>>
>> https://git.savannah.gnu.org/cgit/automake.git/commit/?h=micro=9182df7e4810a411147d523de8cd141e749c5e39
>
> With the "recent" change in Automake branch naming scheme, 'master'
> seems a better fit for this:
>
>   https://lists.gnu.org/archive/html/bug-automake/2017-09/msg00015.html
>
> Thanks.

Hi Mathieu,
Happy to adjust. Would you prefer that I merge micro into master,
then... or something else? Then delete micro? When I noticed that I'd
created that branch (after reading the description in HACKING), I
figured I'd missed something.

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

[Jim Meyering]

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 prefer different
> wording, tell me.

Thanks.
That looks fine.

By the way, I'm waiting to hear from Emacs folks to determine how to
word the NEWS entry for my master-destined elisp-compilation-fix
commit.

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

[Jim Meyering]

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-compilation
rule uses a function that was marked obsolete back in 2009.
Upstream Emacs finally removed support for that function in May,
so anyone using emacs built since then will see the same failure
I saw. It also strikes whenever building from a read-only source
directory.

This change switches the build command to use the "new" way.

I started discussion on emacs-devel last night:
https://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 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 any .el file not in the current
directory.  In emacs-23.1 (July 2009) byte-compile-dest-file-function
became the recommended way to adjust the byte-compiler's destination.
* lib/am/lisp.am (.el.elc): Use byte-compile-dest-file-function,
rather than byte-compile-dest-file.
* t/lisp-readonly-srcdir.sh: New file, to test for the above.
* t/list-of-tests.mk (handwritten_TESTS): Add it.
---
 lib/am/lisp.am|  2 +-
 t/lisp-readonly-srcdir.sh | 46 ++
 t/list-of-tests.mk|  1 +
 3 files changed, 48 insertions(+), 1 deletion(-)
 create mode 100644 t/lisp-readonly-srcdir.sh

diff --git a/lib/am/lisp.am b/lib/am/lisp.am
index 881bf3457..cacbc6feb 100644
--- a/lib/am/lisp.am
+++ b/lib/am/lisp.am
@@ -41,7 +41,7 @@ endif %?INSTALL%
  $(EMACS) --batch \
$(AM_ELCFLAGS) $(ELCFLAGS) \
$$am__subdir_includes -L $(builddir) -L $(srcdir) \
-   --eval "(defun byte-compile-dest-file (f) \"$@\")" \
+   --eval "(setq byte-compile-dest-file-function (lambda (_) \"$@\"))" 
\
--eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"; \
else :; fi

diff --git a/t/lisp-readonly-srcdir.sh b/t/lisp-readonly-srcdir.sh
new file mode 100644
index 0..38b866404
--- /dev/null
+++ b/t/lisp-readonly-srcdir.sh
@@ -0,0 +1,46 @@
+#! /bin/sh
+# Copyright (C) 2017 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+# Ensure that building elisp from a read-only srcdir works.
+
+required=emacs
+. test-init.sh
+
+cat > Makefile.am << 'EOF'
+lisp_LISP = am-one.el
+EOF
+
+cat >> configure.ac << 'EOF'
+AM_PATH_LISPDIR
+AC_OUTPUT
+EOF
+
+echo > am-one.el
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE --add-missing
+
+mkdir sub
+chmod a=rx .
+
+cd sub
+../configure
+$MAKE
+
+test -f am-one.elc
+
+:
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index d234aef48..3dab63d32 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -656,6 +656,7 @@ t/lisp5.sh \
 t/lisp6.sh \
 t/lisp7.sh \
 t/lisp8.sh \
+t/lisp-readonly-srcdir.sh \
 t/lisp-loadpath.sh \
 t/lisp-subdir.sh \
 t/lisp-subdir2.sh \
--
2.14.1.729.g59c0ea183

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

[Jim Meyering]

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 files are
>> > generated only when running 'make all', 'make check' or 'make install'.
>> >
>> > So if they are going to be generated on 'make dist' as well, then the
>> > manual needs a corresponding update.
>>
>> Hi Nick,
>> Thanks for the suggestion, but I do not think it is desired. "make
>> dist" is already defined as building everything that goes into the
>> distribution tarball, and that implies it must also build anything
>> (e.g., from BUILT_SOURCES) that happens to be required to do that.
>
> I agree that it *should* but not that it *must*, because BUILT_SOURCES
> explicitly (by design) bypasses the usual prerequisite mechanisms.
>
> If you use normal prerequisites instead of BUILT_SOURCS everything
> works just fine wrt. distribution, of course, and is the approach I
> would personally recommend in all cases.
>
>> Perhaps more importantly, this is an implementation detail that feels
>> like it should not be made part of the contract that the documentation
>> provides ...
>
> But now with the change applied, as it stands the documentation is
> simply wrong.  For example, this passage from the manual (§9.4 Built
> Sources):
>
>   "... BUILT_SOURCES is honored only by ‘make all’, ‘make check’ and
>   ‘make install’."
>
> is no longer true.  This error can be corrected without explicitly
> documenting the new behaviour, for example by making the list of
> targets non-exhaustive in nature.
>
> Perhaps something like:
>
>   ... BUILT_SOURCES is honored only by certain targets, including ‘make
>   all’, ‘make check’ and ‘make install’.

Thanks for keeping us honest.
That sounds reasonable. Send a patch?

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

[Jim Meyering]

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

[Jim Meyering]

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 not have copies of the sources. Installation
>> processes will continue to copy both .el and .elc files into place.
>
> Oh, so you only split .el and .elc up while building, but they get
> installed into the same place? That's not so bad, though it is, eg, not
> something that Emacs supports in its own build process (in non-srcdir
> builds, .elc still get written into srcdir).
>
> BTW:
>
> ELCFLAGS=-lbytecomp
>
> is presumably another way to solve your issue, for any version of Emacs
> and automake (once bytecomp is loaded you can redefine functions as you wish).

Thanks for the suggestion, Glenn.
However, I've hit a new snag: subdirs.
I posted details and a smaller stand-alone demonstrator on the
emacs-devel thread: TL;DR this automake test fails regardless:

   make check TESTS='t/lisp-subdir.sh'

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

[Jim Meyering]

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)
>>
>> * lib/am/distdir.am (distdir-am): New intermediate target.
>> Interpose this target between $(distdir) and its dependency
>> on $(DISTFILES), so that we can ensure $(BUILT_SOURCES) are
>> all created before we begin creating $(DISTFILES).
> [...]
>>  NEWS   |  3 +++
>>  lib/am/distdir.am  |  7 --
>>  t/dist-vs-built-sources.sh | 56 
>> ++
>>  t/list-of-tests.mk |  1 +
>>  4 files changed, 65 insertions(+), 2 deletions(-)
>>  create mode 100644 t/dist-vs-built-sources.sh
>
> The Automake manual unequivocally states that BUILT_SOURCES files are
> generated only when running 'make all', 'make check' or 'make install'.
>
> So if they are going to be generated on 'make dist' as well, then the
> manual needs a corresponding update.

Hi Nick,
Thanks for the suggestion, but I do not think it is desired. "make
dist" is already defined as building everything that goes into the
distribution tarball, and that implies it must also build anything
(e.g., from BUILT_SOURCES) that happens to be required to do that.
Perhaps more importantly, this is an implementation detail that feels
like it should not be made part of the contract that the documentation
provides, in case some day automake tightens up "make dist" so it
builds only those BUILT_SOURCES files that are actually required to
build the tarball components.

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

[Jim Meyering]

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:
>>>
>>>> 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 any .el file not in the current
>>>> directory.
>>>
>>> In general, Emacs expects .el and .elc to be found in the same
>>> directory. Not adhering to this convention will likely break various
>>> Emacs features. Is this really something automake needs to enable at all?
>>
>> An alternative would be to copy-or-link the .el file into the
>> destination directory. Indeed. That would work without breaking pre-23
>> emacs, so I will adjust my automake patch before pushing it to master.
>
> Hi Glenn,
>
> I've thought about this some more and do not like the idea of
> requiring automake's elisp-compilation rule to make a copy of the
> source file in the destination directory in this slightly contrived
> case. 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 not have copies of the sources.
> Installation processes will continue to copy both .el and .elc files
> into place.

Here is the updated (NEWS addition) patch that I expect to push to
master tomorrow. Feedback welcome. I will also delete the "micro"
branch I created.
From 7558bddcc9cf5ee14441304c2cfc7cffb566daba 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 May of 2017, Emacs' support for using the long-deprecated
byte-compile-dest-file function was removed, and that removal broke
automake's elisp-compiling rule for any .el file not in the current
directory.  In emacs-23.1 (July 2009) byte-compile-dest-file-function
became the recommended way to adjust the byte-compiler's destination.
We expect the removed functionality to be restored for Emacs-26,
albeit with dissuasive diagnostics warning about the imminent removal
of this functionality.  It may be removed in Emacs-27.
* lib/am/lisp.am (.el.elc): Use byte-compile-dest-file-function,
rather than byte-compile-dest-file.
* t/lisp-readonly-srcdir.sh: New file, to test for the above.
* t/list-of-tests.mk (handwritten_TESTS): Add it.
* NEWS (Bugs fixed): Mention this problem.
---
 NEWS  |  5 +
 lib/am/lisp.am|  2 +-
 t/lisp-readonly-srcdir.sh | 46 ++
 t/list-of-tests.mk|  1 +
 4 files changed, 53 insertions(+), 1 deletion(-)
 create mode 100644 t/lisp-readonly-srcdir.sh

diff --git a/NEWS b/NEWS
index 04a285565..dd057b7b1 100644
--- a/NEWS
+++ b/NEWS
@@ -121,6 +121,11 @@ New in ?.?.?:
   - The time printed by 'mdate-sh' is now using the UTC time zone to support
 the reproducible build effort.  (automake bug#20314)

+  - The elisp byte-compilation rule now uses byte-compile-dest-file-function,
+rather than byte-compile-dest-file, which was obsoleted in 2009. We expect
+that Emacs-26 will continue to support the old function, but will complain
+loudly, and that Emacs-27 will remove support for it altogether.
+
 

 New in 1.15.1:
diff --git a/lib/am/lisp.am b/lib/am/lisp.am
index 881bf3457..cacbc6feb 100644
--- a/lib/am/lisp.am
+++ b/lib/am/lisp.am
@@ -41,7 +41,7 @@ endif %?INSTALL%
  $(EMACS) --batch \
$(AM_ELCFLAGS) $(ELCFLAGS) \
$$am__subdir_includes -L $(builddir) -L $(srcdir) \
-   --eval "(defun byte-compile-dest-file (f) \"$@\")" \
+   --eval "(setq byte-compile-dest-file-function (lambda (_) \"$@\"))" 
\
--eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"; \
else :; fi

diff --git a/t/lisp-readonly-srcdir.sh b/t/lisp-readonly-srcdir.sh
new file mode 100644
index 0..38b866404
--- /dev/null
+++ b/t/lisp-readonly-srcdir.sh
@@ -0,0 +1,46 @@
+#! /bin/sh
+# Copyright (C) 2017 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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

[Jim Meyering]

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-compilation
> rule uses a function that was marked obsolete back in 2009.
> Upstream Emacs finally removed support for that function in May,
> so anyone using emacs built since then will see the same failure
> I saw. It also strikes whenever building from a read-only source
> directory.
>
> This change switches the build command to use the "new" way.
>
> I started discussion on emacs-devel last night:
> https://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 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 any .el file not in the current
> directory.  In emacs-23.1 (July 2009) byte-compile-dest-file-function
> became the recommended way to adjust the byte-compiler's destination.
> * lib/am/lisp.am (.el.elc): Use byte-compile-dest-file-function,
> rather than byte-compile-dest-file.
> * t/lisp-readonly-srcdir.sh: New file, to test for the above.
> * t/list-of-tests.mk (handwritten_TESTS): Add it.

Pushed to the micro branch:

https://git.savannah.gnu.org/cgit/automake.git/commit/?h=micro=9182df7e4810a411147d523de8cd141e749c5e39

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

[Jim Meyering]

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-byte-compile" can be used when
>>> the .elc file must be created in a directory separate from the one
>>> containing the .el file.
>>
>> I meant, instead of reinventing the wheel with this part:
>>
>>  --eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"
>>
>> Example:
>>
>> mkdir /tmp/foo /tmp/bar
>> echo '(message "hi")' > /tmp/foo/foo.el
>> emacs --batch \
>>  --eval '(setq byte-compile-dest-file-function (lambda (x) 
>> "/tmp/bar/foo.elc"))' \
>>  -f batch-byte-compile /tmp/foo/foo.el
>>
>> -> generates /tmp/bar/foo.elc
>>
>> batch-byte-compile exists since forever.
>
> Thank you. That looks better, indeed. I will see if I can adapt the
> automake patch accordingly.

I've done that and will push the attached to master later today.
Thanks,
Jim
From e56d637494d4e5c9f0cca0d6417b21d683eb7d6f 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 May of 2017, emacs.master support for using the long-deprecated
byte-compile-dest-file function was removed, and that removal broke
automake's elisp-compiling rule for any .el file not in the current
directory.  In emacs-23.1 (July 2009) byte-compile-dest-file-function
became the recommended way to adjust the byte-compiler's destination.
The removed functionality has been restored for Emacs-26, albeit with
dissuasive diagnostics warning about the imminent removal of this
functionality.  It will be removed in Emacs-27.
* lib/am/lisp.am (.el.elc): Use byte-compile-dest-file-function, rather
than byte-compile-dest-file.  Also, use "-f batch-byte-compile '$<'"
rather than open-coding it, as suggested by Glenn Morris.
* t/lisp-readonly-srcdir.sh: New file, to test for the above.
* t/list-of-tests.mk (handwritten_TESTS): Add it.
* NEWS (Bugs fixed): Mention this problem.
---
 NEWS  |  5 +
 lib/am/lisp.am|  6 +++---
 t/lisp-readonly-srcdir.sh | 46 ++
 t/list-of-tests.mk|  1 +
 4 files changed, 55 insertions(+), 3 deletions(-)
 create mode 100644 t/lisp-readonly-srcdir.sh

diff --git a/NEWS b/NEWS
index 6d8b9d248..7d52aeb93 100644
--- a/NEWS
+++ b/NEWS
@@ -124,6 +124,11 @@ New in ?.?.?:
   - The time printed by 'mdate-sh' is now using the UTC time zone to support
 the reproducible build effort.  (automake bug#20314)

+  - The elisp byte-compilation rule now uses byte-compile-dest-file-function,
+rather than byte-compile-dest-file, which was obsoleted in 2009. We expect
+that Emacs-26 will continue to support the old function, but will complain
+loudly, and that Emacs-27 will remove support for it altogether.
+
 

 New in 1.15.1:
diff --git a/lib/am/lisp.am b/lib/am/lisp.am
index 881bf3457..91a0e0516 100644
--- a/lib/am/lisp.am
+++ b/lib/am/lisp.am
@@ -30,7 +30,7 @@ endif %?INSTALL%
 ## The destination file is normally determined by appending "c" to the
 ## input (which would erronously put it in $(srcdir) in VPATH builds),
 ## so we override that, too.
-   if test "$(EMACS)" != "no"; then \
+   if test '$(EMACS)' != no; then \
  am__dir=. am__subdir_includes=''; \
  case $@ in */*) \
am__dir=`echo '$@' | sed 's,/[^/]*$$,,'`; \
@@ -41,8 +41,8 @@ endif %?INSTALL%
  $(EMACS) --batch \
$(AM_ELCFLAGS) $(ELCFLAGS) \
$$am__subdir_includes -L $(builddir) -L $(srcdir) \
-   --eval "(defun byte-compile-dest-file (f) \"$@\")" \
-   --eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"; \
+   --eval '(setq byte-compile-dest-file-function (lambda (_) "$@"))' \
+   -f batch-byte-compile '$<'; \
else :; fi


diff --git a/t/lisp-readonly-srcdir.sh b/t/lisp-readonly-srcdir.sh
new file mode 100644
index 0..38b866404
--- /dev/null
+++ b/t/lisp-readonly-srcdir.sh
@@ -0,0 +1,46 @@
+#! /bin/sh
+# Copyright (C) 2017 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the

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

[Jim Meyering]

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 .elc files?
>
> Your two issues that affected only automake illustrate that the way
> automake generates .elc files is different to the vast majority of
> Emacs projects.

Thanks for the suggestion, Glenn. However, I don't see how "-f
batch-byte-compile" can be used when the .elc file must be created in
a directory separate from the one containing the .el file. I think
automake generates code the way it does because GNU coding standards
mandate that one be able to build from a read-only hierarchy of
sources (think read-only media).

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

[Jim Meyering]

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 from the one
>> containing the .el file.
>
> I meant, instead of reinventing the wheel with this part:
>
>  --eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"
>
> Example:
>
> mkdir /tmp/foo /tmp/bar
> echo '(message "hi")' > /tmp/foo/foo.el
> emacs --batch \
>  --eval '(setq byte-compile-dest-file-function (lambda (x) 
> "/tmp/bar/foo.elc"))' \
>  -f batch-byte-compile /tmp/foo/foo.el
>
> -> generates /tmp/bar/foo.elc
>
> batch-byte-compile exists since forever.

Thank you. That looks better, indeed. I will see if I can adapt the
automake patch accordingly.

Re: __pycache__ directories and distcleancheck

[Jim Meyering]

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__ directories being leftover in the
> build directory after a distclean. Is the appropriate thing to do here
> simply to list the files in DISTCLEANFILES or is there a better way?
>
> Cheers
>
> Adam
>
>

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

[Jim Meyering]

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 the test do the
> same thing.
>
> I wondered if there were other tests that might have the same problem,
> e.g., if TZ would be better set in test-init.sh (although granted this
> was the only one failing). However, install-sh-option-C.sh is the only
> other test that was setting TZ, and I didn't see others invoking date,
> either. So Jim and I figured just patching vtexi4 is reasonable.
>
> Unrelated but so trivial did not at all seem worth separating: the doc
> in vtexi4.sh referred to itself when it didn't mean to.
>
> Any comments or suggestions before I attempt to push this? --thanks, karl.

Good one. Thank you for tracking that down.
When I applied that, "git am FILE" warned about this:
.git/rebase-apply/patch:14: trailing whitespace.

So please amend that to remove the trailing space in NEWS.

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

[Jim Meyering]

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 AUTOMAKE_UNINSTALLED is (correctly) set in the
> environment at that point, which causes aclocal-1.16 --print-ac-dir
> to forcibly return the empty string, which does not match the expected
> acdir string:
>
>   + aclocal-1.16 -Werror --print-ac-dir
>
>   test "$($ACLOCAL --print-ac-dir)" = "$am_system_acdir"
>   ++ aclocal-1.16 -Werror --print-ac-dir
>   + test '' = /u/karl/gnu/src/akarl/automake-1.16a/_inst/share/aclocal
>   am_exit_trap $?
>   + am_exit_trap 1
>
> Per this bit in the aclocal-1.16 Perl script:
>
>   if (exists $ENV{"AUTOMAKE_UNINSTALLED"})
> {
>   @automake_includes = ();
>   @system_includes = ();
> }
>
> (The --print-ac-dir option simply prints the value of @system_includes.)
>
> So, if I unset AUTOMAKE_UNINSTALLED in the test, it works:
> test "$am_running_installcheck" = yes && unset AUTOMAKE_UNINSTALLED || :
>
> Since this test is intended to check exactly a value that only is set
> normally in an installation, that seems like a reasonable thing to do.

That sounds eminently reasonable.

I don't recall ever knowing about this AUTOMAKE_UNINSTALLED envvar, so
you are now the sole active contributor who has plumbed those depths
:-)

> But I am not sure. Jim, anyone with more experience, can you confirm/deny?
>
> Thanks,
> Karl
>
> P.S. This also fails for me if I run make installcheck after
> building the released automake-1.16.
>
> P.P.S. There are two other tests, print-libdir and aclocal-print-acdir,
> which also fail at the make installcheck step of make distcheck, and not
> sooner. Unfortunately they are not solved by unsetting
> AUTOMAKE_UNINSTALLED, though I think the problem is generally similar.

Good!

Re: dependency tracking error message

[Jim Meyering]

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 spurious "the", so, revising the proposed text:
>
>   AC_MSG_FAILURE([Something went wrong bootstrapping makefile fragments
>   for automatic dependency tracking.  If GNU make was not used, consider
>   re-running the configure script with MAKE="gmake" (or whatever is
>   necessary).  You can also try re-running configure with the
>   '--disable-dependency-tracking' option to at least be able to build
>   the package (albeit without support for automatic dependency tracking).])
>
> Confirm/deny? Further suggestions? --thanks, karl.

Thanks. Looks fine.

I prefer to use the short form of bug URLs, e.g., this:
  https://bugs.gnu.org/35848
rather than this:
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35848

> >From 040f4cc6b8300af4812549d69b07926e5423988a Mon Sep 17 00:00:00 2001
> From: Libor Bukata 
> Date: Thu, 23 May 2019 12:31:31 +0200
> Subject: [PATCH] Improve the error message when the dependency tracking fails

s/when the/when/

> The dependency tracking may fail with a non-intuitive error
> that "Something went wrong ..." if the package expects
> GNU make to process its Makefile.am files and other make
> implementation is used by default (e.g., Solaris make).
> This patch adds a hint to the error message that the user
> may try to specify GNU make command as a configure argument.
>
> Related bug with discussion:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35848
>
> * m4/depout.m4: Added a hint to the error message.

s/Added/Add/

FYI: fixing "maintainer-check" tests

[Jim Meyering]

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
diff lines.


maint.diff
Description: Binary data

automake-1.16.2 released [stable]

[Jim Meyering]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is to announce automake-1.16.2, a stable release.

There have been 38 commits by 12 people in the two years
(almost to the day) since 1.16.1.  Special thanks to Karl Berry
for doing a lot of the recent work preparing for this release.

See 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 Eggert (4)
  Paul Hardy (1)
  Paul Osmialowski (1)
  Vincent Lefevre (1)

Jim [on behalf of the automake maintainers]
==

Here is the GNU automake home page:
http://gnu.org/s/automake/

For a summary of changes and contributors, see:
  http://git.sv.gnu.org/gitweb/?p=automake.git;a=shortlog;h=v1.16.2
or run this command from a git-cloned automake directory:
  git shortlog v1.16.1..v1.16.2

Here are the compressed sources:
  https://ftp.gnu.org/gnu/automake/automake-1.16.2.tar.xz (1.5MB)
  https://ftp.gnu.org/gnu/automake/automake-1.16.2.tar.gz (2.3MB)

Here are the GPG detached signatures[*]:
  https://ftp.gnu.org/gnu/automake/automake-1.16.2.tar.xz.sig
  https://ftp.gnu.org/gnu/automake/automake-1.16.2.tar.gz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify automake-1.16.2.tar.xz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 7FD9FCCB000B

and rerun the 'gpg --verify' command.

==
NEWS

* New features added

  - add zstd support and the automake option, dist-zstd.

* Miscellaneous changes

  - automake no longer requires a @setfilename in each .texi file

* Bugs fixed

  - When cleaning the compiled python files, '\n' is not used anymore in the
substitution text of 'sed' transformations.  This is done to preserve
compatibility with the 'sed' implementation provided by macOS which
considers '\n' as the 'n' character instead of a newline.
(automake bug#31222)

  - For make tags, lisp_LISP is followed by the necessary space when
used with CONFIG_HEADERS.
(automake bug#38139)

  - The automake test txinfo-vtexi4.sh no longer fails when localtime
and UTC cross a day boundary.

  - Emacsen older than version 25, which require use of
byte-compile-dest-file, are supported again.

Also posted as:
  https://savannah.gnu.org/forum/forum.php?forum_id=9706
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEFV0/xQDINEhtHupnf9n8ywAL7u4FAl52thEACgkQf9n8ywAL
7u60Bg/+NgLD/qLC2ZpoMrDYZa7UJfnLdQwtJRHx8yTP6xncY1n+T8PDjM5Q/Ihh
daUWHii4TYapNrBO0xJP//bMkH0ubwvfLCHaZtpBfLL00B25IE8uIcj+1S40LDdo
nrmJARQAqFmWLks4pDl82LHOnXAjzB2hBzN1msl8IEyWTPoAT3t0myQJpt6TFKUo
otLp+DH6MBplgXZjn8ZW1w9ElWhAVo6k20o3DXs0wza1+pEs2Kk0JdJwC1istlMS
hszuOcq8OTOzBhBaK93QEc2XQSojPa729pufPPpAtsWj6Z8K3VbFz0ASoSR6sW4G
x7ZGz2p9zACUuhTXW4hyAK3//iBSeM3A+oY8mq1OhHVFGw0y5UYCMDc5Np4DHiKD
WKfn5+HuttfEKPtye2bH5QZYFaHaKelsxVmYtTkxvql0fWegCN6V3jecxh3RIuWl
F6i8qV//tOp6f0rRdIRmJPY41unF3kubfu4CvoDvZnTTRZ/WRaQ+WJ4q1HVrjzu4
K6Fb/H7PQBq8/QwKqiswCj42aOmP2oG//LSXXmcIIywqWAhieldMhQdUq2IWlzIs
N7FbxoAegGJCpWOJ/5fcn4UR5zL8qBlDRQcVitu6cai3CxWwrIQm6TUPqxuiFQ87
tve8ejvSpFT7EjKaaQUHWhLk3enf8+SfNu9ucgZA2mq0Gp/cvH0=
=Lt5J
-END PGP SIGNATURE-

Re: problems with "make install" directory permissions

[Jim Meyering]

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 writability?
> > I've never understood this forcing of 755.
>
> I expect it was by analogy with regular files, where are already forced to use
> the equivalent of umask 22 when being installed.
>
> This could have been a decision I made years ago when modifying GNU 'install' 
> -
> I've forgotten the details. (No doubt it was a good decision at the time. :-)

>From what I recall, we deliberately avoid making installed things
group-writable because that would induce a security risk in
installations where more than one user is in the same default group.

If I install in such an environment (and don't override the group), I
don't want a peer to be able to modify what I've just installed.

automake-1.16.3 released [stable]

[Jim Meyering]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is to announce automake-1.16.3, a stable release.

There have been 62 commits by 15 people in the 35 weeks since 1.16.2.
Special thanks to Karl Berry and Zack Weinberg for doing so much of the work.

See the NEWS below for a brief summary.

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)
  Robert Wanamaker (1)
  Samuel Tardieu (1)
  Samy Mahmoudi (1)
  Vincent Lefevre (1)
  Zack Weinberg (10)

Jim [on behalf of the automake maintainers]
==

Here is the GNU automake home page:
http://gnu.org/s/automake/

For a summary of changes and contributors, see:
  http://git.sv.gnu.org/gitweb/?p=automake.git;a=shortlog;h=v1.16.3
or run this command from a git-cloned automake directory:
  git shortlog v1.16.2..v1.16.3

Here are the compressed sources:
  https://ftp.gnu.org/gnu/automake/automake-1.16.3.tar.xz (1.6MB)
  https://ftp.gnu.org/gnu/automake/automake-1.16.3.tar.gz (2.3MB)

Here are the GPG detached signatures[*]:
  https://ftp.gnu.org/gnu/automake/automake-1.16.3.tar.xz.sig
  https://ftp.gnu.org/gnu/automake/automake-1.16.3.tar.gz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify automake-1.16.3.tar.xz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 7FD9FCCB000B

and rerun the 'gpg --verify' command.

Please report bugs and problems to ,
and send general comments and feedback to .

==
NEWS

* New features added

  - In the testsuite summary, the "for $(PACKAGE_STRING)" suffix
can be overridden with the AM_TESTSUITE_SUMMARY_HEADER variable.

* Bugs fixed

  - Python 3.10 version number no longer considered to be 3.1.

  - Broken links in manual fixed or removed, and new script
contrib/checklinkx (a small modification of W3C checklink) added,
with accompany target checklinkx to recheck urls.

  - install-exec target depends on $(BUILT_SOURCES).

  - valac argument matching more precise, to avoid garbage in DIST_COMMON.

  - Support for Vala in VPATH builds fixed so that both freshly-generated and
distributed C files work, and operation is more reliable with or without
an installed valac.

  - Dejagnu doesn't break on directories containing spaces.

* Distribution

  - new variable AM_DISTCHECK_DVI_TARGET, to allow overriding the
"make dvi" that is done as part of distcheck.

* Miscellaneous changes

  - install-sh tweaks:
. new option -p to preserve mtime, i.e., invoke cp -p.
. new option -S SUFFIX to attempt backup files using SUFFIX.
. no longer unconditionally uses -f when rm is overridden by RMPROG.
. does not chown existing directories.

  - Removed function up_to_date_p in lib/Automake/FileUtils.pm.
We believe this function is completely unused.

  - Support for in-tree Vala libraries improved.

also posted as:
  https://savannah.gnu.org/forum/forum.php?forum_id=9862
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEFV0/xQDINEhtHupnf9n8ywAL7u4FAl+1+XEACgkQf9n8ywAL
7u5Q/xAAitfd7evm8xIT9AZjwRZ47F+kHV1Y3pIvNa8gWmOUcrpjBmtNXmV533O5
7j3N/nC365azhPtVots2UwdCKBq8KSfoQsil/GFH3hqFw0WfQnSXkr/lKoOxREu+
kQHsSbJeFDN1AoCeSmr8lgkmsfu1e41oqcOw2OTyJqUg74ufuEb5raTMOWtRiHXD
u3RHAYA8XRTVN17DftietFdZh0/YsW0+4eJZlWGpeojfAW569G/givJ1oKv4XkLW
ULtU8WI5H3ArUx39E7k+qSv2ZtgxrdYW3//h35mCmadN7n63rySuciyM2+cKUZx9
VDpQamhMSDunj0A5F+MQx4FI43a8bbEOWDQ/Kr5v5rmANuf+f3Tc2iCCQDQt3KBn
WQ1Ft8XyzykGClRLlXH/8B2t2K+w+1hM4t6zLqZqJ+4hEGq5esUGfPFIirh966Da
lAzi3aC0SQU1MtU1e+dp7C1H3Ebk+z6e/o642HG0AlpgYsv8aWrEbidSGbRsrbSt
R+xprPRsuvZ2u1j6UYsrj7tYM7WYYB/pkBYMQKTdcVbV94WYnNCzBaRxiEByGB9s
Ljil+9PFahltXlxCpC5aqssSFs4G3+1ytUQmh9P62Sg1pRywMlBykc0Tct7nyiKv
fUFBJ1VALj6jQRdL1lsGrQncetseElPMKA0+9YyqMPpx2g/fvRI=
=L/hM
-END PGP SIGNATURE-

Re: Automake testsuite misuses DejaGnu

[Jim Meyering]

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 release as a result.
>
> DejaGnu has always required a DejaGnu testsuite to be rooted at a
> "testsuite" directory and this has long been documented in the manual.
> However, prior to 1.6.3, DejaGnu did not actually depend on this
> requirement being met.  Changes during the development process to
> properly support non-recursive Automake makefiles required relying on
> this requirement to resolve the ambiguity between recursive and
> non-recursive usage.  Several tests in the Automake testsuite do not
> meet this requirement and fail if run with DejaGnu 1.6.3.
>
> The simple change of updating the tests to use a testsuite/ directory
> causes the tests to fail with older versions of DejaGnu, due to lack of
> support for non-recursive "make check" in those versions.  I have not
> yet tried a patch that also switches the tests to use recursive make,
> but I believe that is probably the only way for the tests to pass with
> old and new DejaGnu.
>
> Note that, according to the original author, Rob Savoye, DejaGnu has
> always been intended to require that testsuites be rooted at a
> "testsuite" directory and the behavior that Automake's test cases rely
> on was never supported.
>
> The affected tests are:  check12, dejagnu3, dejagnu4, dejagnu5,
> dejagnu6, dejagnu7, dejagnu-absolute-builddir, dejagnu-relative-srcdir,
> dejgnu-siteexp-extend, dejagnu-siteexp-useredit.
>
> Note that these tests do not all fail with the 1.6.3 release, but will
> all fail with some future release when the undocumented support for a
> testsuite not rooted at "testsuite" will eventually be removed.

Thank you for the analysis and heads-up.
I see that Fedora 34 currently has only dejagnu-1.6.1.
If this is something you can help with now, I can certainly wait a few days.

Even a sample fix for one of the currently-failing tests would be helpful.

snapshot imminent

[Jim Meyering]

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

[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 Karl for doing so much of the work.

There have been 11 commits by 6 people in the 8 weeks since 1.16.4.
See the NEWS below for a brief summary.

Thanks to everyone who has 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]

==
Here is the GNU automake home page:
http://gnu.org/s/automake/

Here are the compressed sources (.sig files are alongside):
  https://meyering.net/automake/automake-1.16g.tar.xz
  https://meyering.net/automake/automake-1.16g.tar.gz

Here are the SHA1 and SHA256 checksums:
0f100809419ecd93ef55fe4db348cf39e21ef3f8  automake-1.16g.tar.gz
64e23e07f1fd3951f80d1090304b328ab134a6a0  automake-1.16g.tar.xz
JstjNQG2jzC1Ci4riJVYwNt3i+FCvdb17hMR4hkZe+o  automake-1.16g.tar.gz
Wow6Qnn2fPmTMVBftfbptuM1PrLfYuB0fH9NkYbvHpA  automake-1.16g.tar.xz

Each SHA256 checksum is base64 encoded, instead of the
hexadecimal encoding that most checksum tools default to.

==
NEWS

* Bugs fixed

  - PYTHON_PREFIX and PYTHON_EXEC_PREFIX are now set according to
Python's sys.* values only if the new configure option
--with-python-sys-prefix is specified. Otherwise, GNU default values
are used, as in the past. (The change in 1.16.3 was too incompatible.)

  - consistently depend on install-libLTLIBRARIES.

* Distribution

  - use const for yyerror declaration in bison/yacc tests.


signature.asc
Description: PGP signature

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

[Jim Meyering]

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 Karl for doing so much of the work.
> >
> > There have been 11 commits by 6 people in the 8 weeks since 1.16.4.
> > See the NEWS below for a brief summary.
>
> I have an early build failure on help2man on Solaris 10 x86:
>
> gmake: Entering directory 
> '/home/dam/mgar/pkg/automake/trunk/work/solaris10-i386/build-isa-pentium_pro-version-1.16/automake-1.16'
>   GEN  bin/automake
>   GEN  bin/aclocal
>   GEN  bin/aclocal-1.16
>   GEN  bin/automake-1.16
>   GEN  t/ax/shell-no-trail-bslash
>   GEN  t/ax/cc-no-c-o
>   GEN  runtest
>   GEN  doc/aclocal.1
>   GEN  doc/automake.1
>   GEN  lib/Automake/Config.pm
>   GEN  doc/aclocal-1.16.1
>   GEN  doc/automake-1.16.1
> help2man: can't get `--help' info from automake-1.16
> Try `--no-discard-stderr' if option outputs to stderr
> gmake: *** [Makefile:3694: doc/automake-1.16.1] Error 255

Thanks for the speedy feedback!
Would you please see if reverting to the version of doc/help2man from
1.16.4 makes it work?

Also, building with V=1 will cause "make" to show more about commands
it is running. That may help, too.

automake-1.16d snapshot

[Jim Meyering]

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.

There have been 41 commits by 11 people in the 35 weeks since 1.16.3.
See 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)
  Reuben Thomas (2)
  Zack Weinberg (1)

Jim [on behalf of the automake maintainers]
==

Here is the GNU automake home page:
http://gnu.org/s/automake/

Here are the compressed sources:
  https://meyering.net/automake/automake-1.16d.tar.xz
  https://meyering.net/automake/automake-1.16d.tar.gz

Their GPG signature .sig files are alongside.

==
NEWS

* New features added

  - In the testsuite summary, the "for $(PACKAGE_STRING)" suffix
can be overridden with the AM_TESTSUITE_SUMMARY_HEADER variable.

* Bugs fixed

  - Python version number 3.10 no longer considered to be 3.1.

  - Broken links in manual fixed or removed, and new script
contrib/checklinkx (a small modification of W3C checklink) added,
with accompany target checklinkx to recheck urls.

  - install-exec target depends on $(BUILT_SOURCES).

  - valac argument matching more precise, to avoid garbage in DIST_COMMON.

  - Support for Vala in VPATH builds fixed so that both freshly-generated and
distributed C files work, and operation is more reliable with or without
an installed valac.

  - Dejagnu doesn't break on directories containing spaces.

* Distribution

  - new variable AM_DISTCHECK_DVI_TARGET, to allow overriding the
"make dvi" that is done as part of distcheck.

* Miscellaneous changes

  - install-sh tweaks:
. new option -p to preserve mtime, i.e., invoke cp -p.
. new option -S SUFFIX to attempt backup files using SUFFIX.
. no longer unconditionally uses -f when rm is overridden by RMPROG.
. does not chown existing directories.

  - Removed function up_to_date_p in lib/Automake/FileUtils.pm.
We believe this function is completely unused.

  - Support for in-tree Vala libraries improved.


signature.asc
Description: PGP signature

Re: automake-1.16d snapshot

[Jim Meyering]

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.
>
> There have been 41 commits by 11 people in the 35 weeks since 1.16.3.
> See 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)
>   Reuben Thomas (2)
>   Zack Weinberg (1)
>
> Jim [on behalf of the automake maintainers]
> ==
>
> Here is the GNU automake home page:
> http://gnu.org/s/automake/
>
> Here are the compressed sources:
>   https://meyering.net/automake/automake-1.16d.tar.xz
>   https://meyering.net/automake/automake-1.16d.tar.gz
>
> Their GPG signature .sig files are alongside.
>
> ==
> NEWS

Oops. I copied the news for 1.6.3 into this snapshot announcement.
Here's the news for the upcoming 1.6.4:

* New features added

  - The PYTHON_PREFIX and PYTHON_EXEC_PREFIX variables are now set from
Python's sys.prefix and sys.exec_prefix; use the new configure options
--with-python_prefix and --with-python_exec_prefix to specify explicitly.

  - Common top-level files can be provided as .md; the non-md version is
used if both are present:
  AUTHORS ChangeLog INSTALL NEWS README README-alpha THANKS

  - CTAGS, ETAGS, SCOPE variables can be set via configure.

  - Silent make output for custom link commands.

  - New option "no-dist-built-sources" skips generating $(BUILT_SOURCES)
before building the tarball as part of "make dist", that is,
omits the dependency of $(distdir): $(BUILT_SOURCES).

* Bugs fixed

  - automake output more reproducible.

  - test-driver less likely to clash with tests writing to the same file.

  - DejaGnu tests always use the directory name, testsuite/, for
compatibility with the newer dejagnu-1.6.3 and with prior versions.

* Distribution

  - config.sub and config.guess updates include restoration of `...`
for maximum portability.