Re: mdate-sh broken on darwin

[Alexandre Duret-Lutz]

>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:

 Stepan> Hello Alexandre,
 Stepan> perhaps I'm missing the context in which is mdate-sh executed, but
 Stepan> couldn't a file name with a space appear there?

Nope

[...]
 Stepan> Wouldn't the following be safer:

 Stepan> case $3 in
 Stepan> ???*) day=$1;;
 Stepan> *) day=$3; shift;;
 Stepan> esac

I think so.  Can any of you make sure this still work on Darwin?
-- 
Alexandre Duret-Lutz

Re: (no subject)

[Alexandre Duret-Lutz]

On Thu, Feb 10, 2005 at 10:58:40AM -0500, Dave Hamm wrote:

> usr/local/bin/automake --version
> automake (GNU automake) 1.9
>
> FAIL: acloca17.test
> FAIL: missing.test
> FAIL: missing2.test
> FAIL: spy.test

Thanks for the detailed report.  You could check whether these failure
style occur with the latest release of Automake? (1.9.4)

If they still do, please send the verbose output of these tests (see
tests/README for instructions).

Re: automake-1.9.5 doesn't install its docs

[Alexandre Duret-Lutz]

On Wed, Feb 16, 2005 at 11:09:56AM -0600, Tim Mooney wrote:
>
> I haven't looked into why yet, but automake 1.9.5 doesn't install its info
> files when doing a `make install'.  automake 1.9.4 and earlier did.
>
> If I do
>
>   make install
>   cd doc && make install
>
> the info files are installed as expected.

Could you post the full output of these two commands?

This release installs its info files in PREFIX/share/info instead of
PREFIX/info as in older releases.  Would it be possible that you were
confused by this change and though "make install" didn't install info
files?

Re: automake not working inspite of AC_CONFIG_FILES([Makefile])

[Alexandre Duret-Lutz]

On Fri, Mar 04, 2005 at 12:40:33PM -0300, Hema K wrote:
>
> i am not able to figure out as to why automake is not working.

Because your 6-year-old version does not understand the new constructs
that have been introduced in this century.  Upgrade.

Re: gettext-0.14.2 fails on parallel build

[Alexandre Duret-Lutz]

On Tue, Mar 15, 2005 at 09:12:43AM +1100, Greg Schafer wrote:
>
> The issue is still present

Could you show it to us?

Thanks.

Re: gettext-0.14.2 fails on parallel build

[Alexandre Duret-Lutz]

>>> "Greg" == Greg Schafer <[EMAIL PROTECTED]> writes:

 Greg> Sure. The output is attached.

Thanks, I'm installing the following fix on HEAD and branch-1-9.

(Perhaps I should update these rules to use AM_CONDITIONAL
before 1.10.  I'll look into this later.)

2005-03-16  Alexandre Duret-Lutz  <[EMAIL PROTECTED]>

* lib/am/lisp.am ($(am__ELCFILES)): Do not attempt to recover
a missing *.elc file if it cannot be created because emacs does
not exist.
* tests/lisp7.test: New file.
* tests/Makefile.am (TESTS): Add lisp7.test.
Report from Greg Schafer.

Index: lib/am/lisp.am
===
RCS file: /cvs/automake/automake/lib/am/lisp.am,v
retrieving revision 1.44
diff -u -r1.44 lisp.am
--- lib/am/lisp.am  1 Feb 2004 12:54:02 -   1.44
+++ lib/am/lisp.am  16 Mar 2005 00:01:30 -
@@ -1,5 +1,5 @@
 ## automake - create Makefile.in from Makefile.am
-## Copyright (C) 1996, 1998, 1999, 2000, 2001, 2002, 2003, 2004
+## Copyright (C) 1996, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
 ## Free Software Foundation, Inc.
 
 ## This program is free software; you can redistribute it and/or modify
@@ -47,8 +47,12 @@
 ## by the user (to disable byte-compilation), and POSIX does not allow
 ## an empty target.
 $(am__ELCFILES): elc-stamp
-## Recover from the removal of $@
-   @if test ! -f $@; then \
+## Recover from the removal of [EMAIL PROTECTED]
+##
+## Make sure not to call `make elc-stamp' if emacs is not available,
+## because as all *.elc files appear as missing, a parallel make would
+## attempt to build elc-stamp several times.
+   @if test "$(EMACS)" != no && test ! -f $@; then \
  rm -f elc-stamp; \
  $(MAKE) $(AM_MAKEFLAGS) elc-stamp; \
else : ; fi
Index: tests/Makefile.am
===
RCS file: /cvs/automake/automake/tests/Makefile.am,v
retrieving revision 1.584
diff -u -r1.584 Makefile.am
--- tests/Makefile.am   1 Mar 2005 23:04:39 -   1.584
+++ tests/Makefile.am   16 Mar 2005 00:01:30 -
@@ -320,6 +320,7 @@
 lisp4.test \
 lisp5.test \
 lisp6.test \
+lisp7.test \
 listval.test \
 location.test \
 longline.test \
Index: tests/lisp7.test
===
RCS file: tests/lisp7.test
diff -N tests/lisp7.test
--- /dev/null   1 Jan 1970 00:00:00 -
+++ tests/lisp7.test16 Mar 2005 00:01:30 -
@@ -0,0 +1,56 @@
+#! /bin/sh
+# Copyright (C) 2005  Free Software Foundation, Inc.
+#
+# This file is part of GNU Automake.
+#
+# GNU Automake 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.
+#
+# GNU Automake 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 GNU Automake; see the file COPYING.  If not, write to
+# the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+# Boston, MA 02111-1307, USA.
+
+# Make sure that lisp_LISP also works when emacs is not installed.
+
+. ./defs || exit 1
+
+set -e
+
+cat > Makefile.am << 'EOF'
+dist_lisp_LISP = am-one.el am-two.el am-three.el
+EOF
+
+cat >> configure.in << 'EOF'
+AM_PATH_LISPDIR
+EMACS=no # Simulate no emacs.
+AC_OUTPUT
+EOF
+
+echo "(require 'am-two)" > am-one.el
+echo "(require 'am-three) (provide 'am-two)" > am-two.el
+echo "(provide 'am-three)" > am-three.el
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE --add-missing
+./configure
+
+$MAKE >stdout
+
+cat stdout
+test 1 -eq `grep 'Warnings can be ignored' stdout | wc -l`
+
+test ! -f am-one.elc
+test ! -f am-two.elc
+test ! -f am-three.elc
+test -f elc-stamp
+
+$MAKE distcheck

-- 
Alexandre Duret-Lutz

Re: gettext-0.14.2 fails on parallel build

[Alexandre Duret-Lutz]

On Wed, Mar 16, 2005 at 03:08:06PM +0100, Bruno Haible wrote:
> Alexandre Duret-Lutz wrote:
> > Thanks, I'm installing the following fix on HEAD and branch-1-9.
> > ...
> > -## Recover from the removal of $@
> > -   @if test ! -f $@; then \
> > +## Recover from the removal of [EMAIL PROTECTED]
> > +##
> > +## Make sure not to call `make elc-stamp' if emacs is not available,
> > +## because as all *.elc files appear as missing, a parallel make would
> > +## attempt to build elc-stamp several times.
> > +   @if test "$(EMACS)" != no && test ! -f $@; then \
>
> IMO this does not fix the bug. It only makes it less likely to appear.
>
> What happened was: In the rules
>
> elc-stamp: $(LISP)
> @rm -f elc-temp && touch elc-temp
> ...
> @mv -f elc-temp $@
>
> 3 independent 'make' processes started working on this rule.

It seems you are trying to allow this, but that is precisely the bug I
wanted to fix.  The other points are consequences.  Only one instance
of any rule in a Makefile should run at the same time.

> Process 1 created elc-temp.
> Process 2 re-created elc-temp.
> Then process 1 and process 2 performed the "..." task.
> Process 1 moved elc-temp to elc-stemp.
> Process 2 attempted to do so as well, but elc-temp was already gone.
>
> For this to happen, the contents of the "..." task is irrelevant.

Well, if you want to allow parallel executions of "...", its contents
really matter since all instance are likely to use the same ressources
(e.g. compiling the same files... eww).

But really we do not want this: there is no reason to build the same
target more than once.

> Adding "test "$(EMACS)" != no" doesn't change the problem.

It gets rid of these 3 independent 'make' processes.  (Those
are not started when emacs exists, because when emacs exists
the *.elc files have already been built and the `test ! -f $@'
above fails.)


Here is another angle to the problem that might help: this whole issue
would not exist if the `$(am__ELCFILES): elc-stamp' rule did not have
any command.

Re: gettext-0.14.2 fails on parallel build

[Alexandre Duret-Lutz]

>>> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:

 Bruno> Your modification does not fix this, because
 Bruno> - It didn't change the dependencies of this rule, or the rules which
 Bruno> depend on this one. Therefore this rule can still be started by two
 Bruno> parallel processes.
 Bruno> - The first line, "rm -f elc-temp && touch elc-temp", does nothing to
 Bruno> prevent parallel execution.

My impression is that you believe `make -j N all' could spawn
several processes on this elc-stamp target.  This is not true.
Make starts only one command per target, and wait for this
target to be completed before building any other dependent
targets.

The only way to have the same target built several times is to
explicitly start separate make processes yourself.  (That was
what was happening.)

When make encounters the following fragment

all: one.elc two.elc three.elc

one.elc two.elc three.elc: elc-stamp
...

it first has to build the dependency: elc-stamp.  Only one
process does this.  Then, and only after elc-stamp has been
built, make can run the three "..." commands in parallel.  It
won't start the "..." commands their dependencies (here elc-stamp)
are built.

In Greg's output this is clearly apparent.  The elc-stamp is run
a first time alone.  After it has finished, three `make
elc-stamp' are explicitly started by the three parallel instance
of the "..." rule.

Hope it's clearer.

 Bruno> The only nit on this fix is that it doesn't work on
 Bruno> filesystems that don't support hard links (like the BeOS
 Bruno> filesystem).

The automake's aux scripts use mkdir as atomic test-and-set.
-- 
Alexandre Duret-Lutz

Re: gettext-0.14.2 fails on parallel build

[Alexandre Duret-Lutz]

>>> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:

 Bruno> So it must mean: "If the user has removed *.elc but elc-stamp is still
 Bruno> there, then remake elc-stamp." This scenario can still occur, and will
 Bruno> still lead to multiple parallel processes [except if only one .elc file
 Bruno> was missing], and will still fail the same way.

Yes, I agree.  If users mutilate their build tree they can only
recover with a non-parallel make.  But IMO a fix for this
belongs to the rule that starts those multiple `$(MAKE)
elc-stamp' processes, not to the elc-stamp rule.  IOW locks are
not needed in regular builds, they would only be needed to
prevent multiple *recover* rules to start `$(MAKE) elc-stamp'.
-- 
Alexandre Duret-Lutz

Re: gettext-0.14.2 fails on parallel build

[Alexandre Duret-Lutz]

>>> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:

 Bruno> Ok, what about this (untested) patch?

I'll do something like that.  The "recover" idiom is not only
used here, and there are all those trap/exit portability issues
to handle.  I just don't have the time for this now :(
-- 
Alexandre Duret-Lutz

Re: automake-1.9.5

[Alexandre Duret-Lutz]

On Fri, Mar 18, 2005 at 10:04:28PM +0100, Tom Burger wrote:
> Hi!
>
> I've been trying to compile automake on my computer. 507 tests failed...

Thanks for the report.
Please run any of the failing test to see why it is failing.
(See tests/README.)

Re: gettext-0.14.2 fails on parallel build

[Alexandre Duret-Lutz]

>>> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
[...]
 Bruno> $(am__ELCFILES): elc-stamp
 Bruno> ## Recover from the removal of [EMAIL PROTECTED]
 Bruno> ##
 Bruno> ! ## Do not call `make elc-stamp' if emacs is not available, because it 
would
 Bruno> ! ## be useless.
 Bruno> @if test "$(EMACS)" != no && test ! -f $@; then \
 Bruno> ! ## Mutual exclusion locking to ensure that if multiple processes need 
to
 Bruno> ! ## rebuild elc-stamp, only the first one does it, and the followers 
wait.
 Bruno> ! trap 'rm -rf elc-lock elc-stamp' 1 2 3 15; \
 Bruno> ! if mkdir elc-lock 2>/dev/null; then \
 Bruno> ! ## This code is being executed by the first process.
 Bruno> !   rm -f elc-stamp; \
 Bruno> !   $(MAKE) $(AM_MAKEFLAGS) elc-stamp; \
 Bruno> !   rmdir elc-lock; \
 Bruno> ! else \
 Bruno> ! ## This code is being executed by the follower processes.
 Bruno> ! ## Wait until the first process is done.
 Bruno> !   while test -d elc-lock; do sleep 1; done; \
 Bruno> ! ## Succeed if and only if the first process succeeded.
 Bruno> !   test -f elc-stamp; exit $$?; \
 Bruno> ! fi; \
 Bruno> else : ; fi
  
This code still has a race if one of the followers gets signaled
after its trap has been set.  Then it will erase elc-lock, and
another follower can create it.

Any idea?
-- 
Alexandre Duret-Lutz

Re: TESTS not included in dist.

[Alexandre Duret-Lutz]

>>> "Derek" == Derek Price <[EMAIL PROTECTED]> writes:

 Derek> Is there a good reason the contents of a TESTS variable, when it
 Derek> exists, are not distributed by default?

Built TESTS.
-- 
Alexandre Duret-Lutz

Re: ylwrap should be included for any Yacc compilations.

[Alexandre Duret-Lutz]

>>> "Derek" == Derek Price <[EMAIL PROTECTED]> writes:

 Derek> ylwrap appears to take care of the problem that Yacc compilers like to
 Derek> generate #line directives in generated C sources with complete paths
 Derek> to source files. 

So does the inline rule.  Can you provide instructions to
reproduce the problem ?
-- 
Alexandre Duret-Lutz

Re: automake 1.9.5 minor doc updates

[Alexandre Duret-Lutz]

>>> "Karl" == Karl Berry <[EMAIL PROTECTED]> writes:

 Karl> In reading through some of the current automake manual, I found a few
 Karl> small items, see diff below.  

Thanks.  Most of these were already fixed in CVS.  
I'm installing the patch below on HEAD and branch-1-9.

Note that I prefer to point people to
http://www.gnu.org/software/texinfo/ instead of the viewcvs url
you suggested because 
  1) that is the URL embedded in the file and
  2) this way we don't have to update the Automake manual each time
 texinfo.tex is moved to another place (as just happened)

The texinfo.tex link at http://www.gnu.org/software/texinfo/
still points to ...gnulib/config/texinfo.tex, which no longer
exists.

 Karl> The Hello code is in flux, so I didn't bother to update
 Karl> that.

Don't.  As we have already discussed this section will disappear.

 Karl> Node: Uniform
 Karl> For instance, installation of HTML files is part of Automake, you
 Karl> could use this to install raw HTML documentation:
 Karl> htmldir = $(prefix)/html
 Karl> html_DATA = automake.html

 Karl> I don't understand this.  

I bet you don't.  It used to read ``For instance, until
installation of ...''.  Somehow ``until'' disappeared.

 Karl> Does the user really have to define htmldir?

Presently, yes.

 Karl> Isn't that defined by default now?  

Only CVS Autoconf defines it.  But that's enough to warrant a
rewrite of this example, so it doesn't confuse people when
Autoconf 2.60 is eventually released.


2005-03-30  Alexandre Duret-Lutz  <[EMAIL PROTECTED]>

* doc/automake.texi (Uniform): Use xmldir instead of htmldir as
example, since the GCS now define htmldir.
(Auxiliary Programs): Mention config-ml.in and symlink-tree.
Give a URL for texinfo.tex.
(Public macros): Sort alphabetically, and move obsolete macros...
(Obsolete macros): ... here.
Prompted by Karl Berry.

Index: doc/automake.texi
===
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.110
diff -u -r1.110 automake.texi
--- doc/automake.texi   29 Mar 2005 23:41:28 -  1.110
+++ doc/automake.texi   30 Mar 2005 19:44:44 -
@@ -149,6 +149,7 @@
 Autoconf macros supplied with Automake
 
 * Public macros::   Macros that you can use.
+* Obsolete macros:: Macros that you should stop using.
 * Private macros::  Macros that you should not use.
 
 Directories
@@ -587,14 +588,12 @@
 is valid if a variable of the same name with @samp{dir} appended is
 defined (e.g., @samp{zardir}).
 
[EMAIL PROTECTED] HTML installation, example
-
-For instance, installation of HTML files is part of Automake, you could
-use this to install raw HTML documentation:
+For instance, the following snippet will install @file{file.xml} into
[EMAIL PROTECTED](datadir)/xml}.
 
 @example
-htmldir = $(prefix)/html
-html_DATA = automake.html
+xmldir = $(datadir)/xml
+xml_DATA = file.xml
 @end example
 
 @cindex @samp{noinst_} primary prefix, definition
@@ -696,6 +695,11 @@
 @file{Makefile} can do its work properly.  There are a fairly large
 number of them, and we list them here.
 
+Although all of these files are distributed and installed with
+Automake, a couple of them are maintained separately.  The Automake
+copies are updated before each release, but we mention the original
+source in case you need more recent versions.
+
 @table @code
 @item ansi2knr.c
 @itemx ansi2knr.1
@@ -714,10 +718,15 @@
 support new architectures and fix probes broken by changes in new
 kernel versions.  Each new release of Automake comes with up-to-date
 copies of these programs.  If your copy of Automake is getting old,
-You are encouraged to fetch the latest versions of these files from
+you are encouraged to fetch the latest versions of these files from
 @url{http://savannah.gnu.org/cvs/?group=config} before making a
 release.
 
[EMAIL PROTECTED] config-ml.in
+This file is not a program, it is a @file{configure} fragment used for
+multilib support (@pxref{Multilibs}).  This file is maintained in the
+GCC tree at @url{http://gcc.gnu.org/cvs.html}.
+
 @item depcomp
 This program understands how to run a compiler so that it will
 generate not only the desired output but also dependency information
@@ -753,9 +762,17 @@
 @item py-compile
 This is used to byte-compile Python scripts.
 
[EMAIL PROTECTED] symlink-tree
+This program duplicates a tree of directories, using symbolic links
+instead of copying files.  Such operation is performed when building
+multilibs (@pxref{Multilibs}).  This file is maintained in the GCC
+tree at @url{http://gcc.gnu.org/cvs.html}.
+
 @item texinfo.tex
-Not a program, this file is required for @samp{make dvi}, @samp{make ps}
-and @samp{make pdf} to work when Texinfo sources are in the package.
+N

Re: ylwrap should be included for any Yacc compilations.

[Alexandre Duret-Lutz]

On Mon, Apr 04, 2005 at 04:04:33PM -0400, Derek Price wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Is the description in this email sufficient:
> ?

No.  Isn't that the same link that was in your original report?

If I read this whitout reading your mail, my answer is "Upgrade to
Automake >= 1.9.1".  But your initial mail mentions 1.9.5.

> I would argue that this behavior with regards to #line directives is
> non-optimal in most, if not all, distributed applications and am
> guessing someone on the Automake team already agrees with me since the
> ylwrap script already strips the full paths from the #line
> directives.

So does the inline rule.

Re: ylwrap should be included for any Yacc compilations.

[Alexandre Duret-Lutz]

Hi Derek,

Sorry for the long delay.

>>> "Derek" == Derek Price <[EMAIL PROTECTED]> writes:

 Derek> Glancing at the inline rule which was being used:

 Derek> ~sed '/^#/ s|y\.tab\.c|$@|' y.tab.c >[EMAIL PROTECTED] && mv [EMAIL 
PROTECTED] $@

 Derek> Only the filename portion of the path is being replaced here.  The
 Derek> ylwrap script actually replaces an absolute path in the #line
 Derek> directive with just the filename:

Thank you, that's clear to me now.  Sorry I was so dense.

Using ylwrap in all cases is already planed for automake-1.10
for other reasons, so I guess that will be OK with you.

For the meantime an easy way to trick automake-1.9 into using
ylwrap is

   yourprogram_SOURCES = ... real_parser.yy ...
   nodist_EXTRA_yourprogram_SOURCES = dummy.yy

(The end of Section `Libtool Convenience Libraries' (sic)
explains a similar trick.)

 Derek> ...

 Derek> ~   # Quote $INPUT_DIR so we can use it in a regexp.
 Derek> ~   # FIXME: really we should care about more than `.' and `\'.
 Derek> ~   input_rx=`echo "$input_dir" | sed 's,,,g;s,\\.,.,g'`

If there wasn't that FIXME I'd inject this line in the inline
rule of branch-1-9.  I've made a note to fix that in 1.10 as well.
I'm sure libtool has some requoting machinery we can steal.
-- 
Alexandre Duret-Lutz

Re: A problem with "intermediate files"

[Alexandre Duret-Lutz]

Sorry for the delay.

>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:

[...]

 Stepan> SUFFIXES = .list

That should be needed only if your extensions do not start with
a dot.  I thought I had this documented, but I cannot find
where.

 Stepan> gnumeric_SOURCES = ... gnm-genmarshals.list ...
 Stepan> .list.c:
 Stepan> 

 Stepan> So make is supposed to generate gnm-genmarshals.lo by
 Stepan> chaining the rules

 Stepan> .list.c:
 Stepan> .c.lo:

 Stepan> I noticed two problems:

 Stepan> 1) With GNU make, the "intermediate file", gnm-marshalers.c is deleted
 Stepan> after gnm-genmarshals.lo is created.  But when you run make for the
 Stepan> second time, probably as "make install", gnm-marshalers.c is mentioned
 Stepan> in .deps/gnm-marshalers.Plo, so it is generated again, and all targets
 Stepan> depending on it are refreshed.
 Stepan> (See http://bugzilla.gnome.org/show_bug.cgi?id=172211 , for a more
 Stepan> detailed explanation.)

 Stepan> 2) Some historic make implementations are not able to chain implicit
 Stepan> rules, so the build fails.
 Stepan> (See http://bugzilla.gnome.org/show_bug.cgi?id=172212 .)

 Stepan> An elegant solution for problem 1) is to add a dummy rule:

 Stepan> non-intermediate: gnm-genmarshals.c

 Stepan> (As soon as a file is mentioned as a prerequisite of a
 Stepan> rule, it cannot be treated as an "intermediate file".)

 Stepan> According to my experiences with the "historic
 Stepan> implementations of make", this rule also fixes problem
 Stepan> 2).  (I have only one such historic make at hand, on an
 Stepan> "OSF1 V4.0 alpha" system.)

Then, why not simply output

gnm-genmarshals.c: gnm-genmarshals.list

?

(See also tests/suffix8.test and its history.)

 Stepan> But I think Automake could handle this automatically.

Would be nice.
-- 
Alexandre Duret-Lutz

Re: Logical conflict between EXTRA_DIST and AC_OUTPUT

[Alexandre Duret-Lutz]

>>> "Sergey" == Sergey Udaltsov <[EMAIL PROTECTED]> writes:

 Sergey> Hi ppl
 Sergey> In Makefile.am there is a line:
 Sergey> EXTRA_DIST=... mypackage.spec

 Sergey> At the same time I mention in configure.in AC_OUTPUT mypackage.spec -
 Sergey> which is generated from mypackage.spec.in. Is is correct that "make
 Sergey> distclean" removes the mypackage.spec (because it is in AC_OUTPUT).
 Sergey> Probably it should not remove it (because it is in EXTRA_DIST)?

If a file is distributed, it should not be rebuild by configure.
If a file is build by configure, there is not point in distributing it.

In your case I suggest you build mypackage.spec from a custom
rule in Makefile.am.  See how Automake builds its copy if
m4/amversion.m4 for instance.
-- 
Alexandre Duret-Lutz

Re: Processing of automake comments

[Alexandre Duret-Lutz]

>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:

 Stepan> Could you please fix this?

http://lists.gnu.org/archive/html/automake-patches/2005-03/msg00003.html
-- 
Alexandre Duret-Lutz

Re: Makefile bugs

[Alexandre Duret-Lutz]

The answer to your question is in the FAQ.
-- 
Alexandre Duret-Lutz

Re: Automake not liking spaces in path names.

[Alexandre Duret-Lutz]

>>> "Chris" == Chris Ison <[EMAIL PROTECTED]> writes:

 Chris> I am told this is an automake bug.

What version ?
-- 
Alexandre Duret-Lutz

Re: abs_top_builddir not working?

[Alexandre Duret-Lutz]

>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:

[...]

 Stepan> I suggest that Automake automatically sets these make variables:

 Stepan> abs_srcdir
 Stepan> abs_builddir
 Stepan> abs_top_srcdir
 Stepan> abs_top_builddir

Why not AC_SUBST these variables in Autoconf ?  Let's work on
solution that don't require modifying Automake each time
Autoconf introduce a new variable.
-- 
Alexandre Duret-Lutz

Re: abs_top_builddir not working?

[Alexandre Duret-Lutz]

>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:

[...]

 Stepan> Yes, I could use an m4_if inside AC_SUBST to handle them specially.

That means maintaining a list of variables far from their definitions.

 Stepan> Or perhaps you could trace a different macro, not directly AC_SUBST.

That sounds the right thing to do to me.  This would allow
anybody to get the precise list of all variables that are
substituted in the output, something you cannot do right now.

 Stepan> Yet I still think having these in header-vars.am is the siplest way.

That means maintaining a list of variables even farer from their
definitions.  I'd rather aim to remove anything from this file
that is not purely Automake-specific.  E.g., the definition of
srcdir, and top_srcdir have nothing to do here: Autoconf should
tell Automake these variables exist.
-- 
Alexandre Duret-Lutz

Re: abs_top_builddir not working?

[Alexandre Duret-Lutz]

>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:

 Stepan> Hello,
 Stepan> On Wed, May 18, 2005 at 11:04:04AM +0200, Alexandre Duret-Lutz wrote:
 Stepan> Or perhaps you could trace a different macro, not directly AC_SUBST.
 >> 
 >> That sounds the right thing to do to me.

 Stepan> OK.  Alexandre, I'm new to this, could you please
 Stepan> suggest a name for the macro?

I'm not good at naming things.  AC_SUBST_TRACE (like
AC_DEFINE_TRACE) or AC_OUTPUT_VARIABLE ?

[...]

 Stepan> 3) You said you don't want `buildir = .' in
 Stepan> Automake-generated makefiles. 

I didn't want Automake to output such useless variable definition.
But if Autoconf tells Automake to do it, it's no longer my problem :)

 Stepan> Can you implement this exception on Automake's side?

I'm all for clean interfaces.  No exceptions.  If Autoconf tells
Automake to define it, let's define it.
-- 
Alexandre Duret-Lutz

Re: dvips may require inputs from source directory

[Alexandre Duret-Lutz]

>>> "Brian" == Brian Gough <[EMAIL PROTECTED]> writes:

 Brian> For out of tree builds, dvips may require files on TEXINPUTS, like
 Brian> texi2dvi (e.g. eps files for figures).  Patch for automake-1.9.5
 Brian> below.

Thank you.  I'm installing this on HEAD and branch-1-9.

2005-05-24  Brian Gough  <[EMAIL PROTECTED]>  (tiny change)

* lib/am/texinfos.am (.dvi.ps): Add $(am__TEXINFO_TEX_DIR) to TEXINPUTS.

Index: THANKS
===
RCS file: /cvs/automake/automake/THANKS,v
retrieving revision 1.267
diff -u -r1.267 THANKS
--- THANKS  1 Mar 2005 23:04:38 -   1.267
+++ THANKS  24 May 2005 16:37:57 -
@@ -34,6 +34,7 @@
 Braden N. McDaniel [EMAIL PROTECTED]
 Brendan O'Dea  bod@compusol.com.au
 Brian Ford [EMAIL PROTECTED]
+Brian Gough[EMAIL PROTECTED]
 Brian Jones[EMAIL PROTECTED]
 Bruce Korb [EMAIL PROTECTED]
 Bruno Haible   [EMAIL PROTECTED]
Index: lib/am/texinfos.am
===
RCS file: /cvs/automake/automake/lib/am/texinfos.am,v
retrieving revision 1.116
diff -u -r1.116 texinfos.am
--- lib/am/texinfos.am  14 May 2005 20:28:53 -  1.116
+++ lib/am/texinfos.am  24 May 2005 16:38:59 -
@@ -1,7 +1,7 @@
 ## automake - create Makefile.in from Makefile.am
 
-## Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 
2004
-## Free Software Foundation, Inc.
+## Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
+## 2003, 2004, 2005 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
@@ -57,6 +57,7 @@
 if %?LOCAL-TEXIS%
 DVIPS = dvips
 .dvi.ps:
+   TEXINPUTS="$(am__TEXINFO_TEX_DIR)$(PATH_SEPARATOR)$$TEXINPUTS" \
    $(DVIPS) -o $@ $<
 endif %?LOCAL-TEXIS%
 
-- 
Alexandre Duret-Lutz

Re: Infinite loop in mdate-sh

[Alexandre Duret-Lutz]

>>> "James" == James Youngman <[EMAIL PROTECTED]> writes:

 James> +# GNU ls unserstands $TIME_STYLE.  Leaving it set at "+%Y-%m-%d 
%H:%M:%S" for 
 James> +# example will cause this script to go into an infinite loop.
 James> +unset TIME_STYLE

unset is not portable.  
Can we override TIME_STYLE with some safe value? Which one? 
What happens when this is set to the empty string?
-- 
Alexandre Duret-Lutz

Re: minor typo in manual

[Alexandre Duret-Lutz]

>>> "Toralf" == Toralf Förster <[EMAIL PROTECTED]> writes:

 Toralf> " would be expansed during the second definition" but
 Toralf> it should be expan*d*ed isn't it ?

Thank you.
-- 
Alexandre Duret-Lutz

Re: abs_top_builddir not working?

[Alexandre Duret-Lutz]

>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:

[...]

 Stepan> Actually, I'm considering the possibility to make one exception
 Stepan> on Autoconf side: @configure_input@ is a strange substitution.
 Stepan> Do you think it should be reported by AC_SUBST_TRACE, too?

Either way is fine with me.
-- 
Alexandre Duret-Lutz

Re: typos in 1.9.5 manual

[Alexandre Duret-Lutz]

I'm installing this on HEAD and branch-1-9.
Thanks Karl!  

2005-06-29  Alexandre Duret-Lutz  <[EMAIL PROTECTED]>

* doc/automake.texi (Include, Extending aclocal): Typos.
Report from Karl Berry.

Index: doc/automake.texi
===
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.116
diff -u -r1.116 automake.texi
--- doc/automake.texi   8 Jun 2005 18:46:17 -   1.116
+++ doc/automake.texi   29 Jun 2005 20:33:04 -
@@ -1981,7 +1981,7 @@
 and many third party macros are underquoted; and we have to apologize
 for this temporary inconvenience.  The reason we have to be stricter
 is that a future implementation of @command{aclocal} (@pxref{Future of
-aclocal}) will have to temporary include all these third party
+aclocal}) will have to temporarily include all these third party
 @file{.m4} files, maybe several times, including even files that are
 not actually needed.  Doing so should alleviate many problems of the
 current implementation, however it requires a stricter style from the
@@ -7282,7 +7282,7 @@
 condition applies to the entire contents of that fragment.
 
 Makefile fragments included this way are always distributed because
-there are needed to rebuild @file{Makefile.in}.
+they are needed to rebuild @file{Makefile.in}.
 
 @node Conditionals
 @chapter Conditionals
-- 
Alexandre Duret-Lutz

Re: Infinite loop in mdate-sh

[Alexandre Duret-Lutz]

Thanks all, and sorry for the delay.  I'm installing the
following on HEAD and branch-1-9.

(I think any justification of why unset must not be used really
belongs to the Autoconf manual.)

2005-06-28  Stepan Kasal  <[EMAIL PROTECTED]>
    Alexandre Duret-Lutz  <[EMAIL PROTECTED]>

* lib/mdate-sh: Avoid infinite loop with GNU ls when TIME_STYLE is set.
* tests/txinfo28.test: Set TIME_STYLE.
Report from Vincent Lefevre and James Youngman.

Index: THANKS
===
RCS file: /cvs/automake/automake/THANKS,v
retrieving revision 1.270
diff -u -r1.270 THANKS
--- THANKS  23 Jun 2005 22:19:55 -  1.270
+++ THANKS  29 Jun 2005 20:15:59 -
@@ -269,6 +269,7 @@
 Ulrich Eckhardt[EMAIL PROTECTED]
 Václav Haisman [EMAIL PROTECTED]
 Vadim Zeitlin  [EMAIL PROTECTED]
+Vincent LefevreVincent Lefevre <[EMAIL PROTECTED]>
 Volker Boerchers   [EMAIL PROTECTED]
 Werner John[EMAIL PROTECTED]
 Werner Koch[EMAIL PROTECTED]
Index: lib/mdate-sh
===
RCS file: /cvs/automake/automake/lib/mdate-sh,v
retrieving revision 1.17
diff -u -r1.17 mdate-sh
--- lib/mdate-sh14 May 2005 20:28:50 -  1.17
+++ lib/mdate-sh29 Jun 2005 20:15:59 -
@@ -1,7 +1,7 @@
 #!/bin/sh
 # Get modification time of a file or directory and pretty-print it.
 
-scriptversion=2005-05-14.22
+scriptversion=2005-06-29.22
 
 # Copyright (C) 1995, 1996, 1997, 2003, 2004, 2005 Free Software
 # Foundation, Inc.
@@ -59,7 +59,15 @@
 LC_TIME=C
 export LC_TIME
 
-save_arg1="$1"
+# GNU ls changes its time format in response to the TIME_STYLE
+# variable.  Since we cannot assume `unset' works, revert this
+# variable to its documented default.
+if test "${TIME_STYLE+set}" = set; then
+  TIME_STYLE=posix-long-iso
+  export TIME_STYLE
+fi
+
+save_arg1=$1
 
 # Find out how to get the extended ls output of a file or directory.
 if ls -L /dev/null 1>/dev/null 2>&1; then
Index: tests/txinfo28.test
===
RCS file: /cvs/automake/automake/tests/txinfo28.test,v
retrieving revision 1.3
diff -u -r1.3 txinfo28.test
--- tests/txinfo28.test 14 May 2005 20:28:56 -  1.3
+++ tests/txinfo28.test 29 Jun 2005 20:16:00 -
@@ -1,5 +1,5 @@
 #! /bin/sh
-# Copyright (C) 2002, 2003  Free Software Foundation, Inc.
+# Copyright (C) 2002, 2003, 2005  Free Software Foundation, Inc.
 #
 # This file is part of GNU Automake.
 #
@@ -27,6 +27,11 @@
 
 set -e
 
+# This setting, when honored by GNU ls, used to cause an infinite loop
+# in mdate-sh.
+TIME_STYLE="+%Y-%m-%d %H:%M:%S"
+export TIME_STYLE
+
 echo AC_OUTPUT >> configure.in
 
 cat > Makefile.am << 'END'

-- 
Alexandre Duret-Lutz

Re: Infinite loop in mdate-sh

[Alexandre Duret-Lutz]

>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:

 Stepan> Two tiny comments:

 >> +Vincent LefevreVincent Lefevre <[EMAIL PROTECTED]>

Oops, thanks!

 Stepan> It seems this is the first time when you repeat the full name in the 
email.

 >> +if test "${TIME_STYLE+set}" = set; then
 >> +  TIME_STYLE=posix-long-iso
 >> +  export TIME_STYLE
 >> +fi

 Stepan> I see no reason for the `export' here.  

`export'
 The builtin `export' dubs a shell variable "environment variable".
 Each update of exported variables corresponds to an update of the
 environment variables.  Conversely, each environment variable
 received by the shell when it is launched should be imported as a
 shell variable marked as exported.

 Alas, many shells, such as Solaris 2.5, IRIX 6.3, IRIX 5.2, AIX
 4.1.5, and Digital UNIX 4.0, forget to `export' the environment
 variables they receive.  As a result, two variables coexist: the
 environment variable and the shell variable.  The following code
 demonstrates this failure:

  #! /bin/sh
  echo $FOO
  FOO=bar
  echo $FOO
  exec /bin/sh $0

 when run with `FOO=foo' in the environment, these shells will print
 alternately `foo' and `bar', although it should only print `foo'
 and then a sequence of `bar's.

 Therefore you should `export' again each environment variable that
 you update.

-- 
Alexandre Duret-Lutz

Re: HEAD bootstrap broken

[Alexandre Duret-Lutz]

On Sat, Jul 02, 2005 at 08:30:57AM -0600, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> CVS HEAD currently fails to bootstrap, when using CVS autoconf:

Try refreshing your copy of CVS Autoconf first.

Re: missing feature: CFLAGS per library compilation unit

[Alexandre Duret-Lutz]

>>> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
[...]
 Bruno> How can I define additional CFLAGS that apply to bar.lo
 Bruno> but not to baz.lo?
[...]
 Bruno> How can I define additional CFLAGS that apply to foo.o and bar.o
 Bruno> but not to common.o?
[...]

Using convenience (libtool or not) libraries as a workaround, sorry.
See "Per-Object Flags" in the FAQ.
-- 
Alexandre Duret-Lutz

Re: AM_PROG_MKDIR_P overcautious?

[Alexandre Duret-Lutz]

>>> "SK" == Stepan Kasal <[EMAIL PROTECTED]> writes:

 SK> Hello,
 SK> regarding the bug report about `mkdir -p -- .', archived at:
 SK> http://lists.gnu.org/archive/html/bug-automake/2004-07/msg00052.html

 SK> I think that the problem described here is a bug in a vendor mkdir.
 SK> Generally, mkdir -p on any existing directory should succeed, no matter
 SK> whether it is writable or not.

 SK> I asked Harlan Stenn, the author of the bug report, about the details,
 SK> but he doesn't remember.

OK.  Let's just fix the comment then.  I can't see any
compelling reason to add that dot back, especially since it took
several versions to get this check to a point where nobody is
complaining about it.

I'm installing this on HEAD.

2005-08-07  Alexandre Duret-Lutz  <[EMAIL PROTECTED]>

* m4/mkdirp.m4: Update misleading comment about `mkdir -p .'.
Prompted by Stepan Kasal.

Index: m4/mkdirp.m4
===
RCS file: /cvs/automake/automake/m4/mkdirp.m4,v
retrieving revision 1.7
diff -u -r1.7 mkdirp.m4
--- m4/mkdirp.m49 Jan 2005 14:46:21 -   1.7
+++ m4/mkdirp.m47 Aug 2005 08:08:05 -
@@ -25,30 +25,34 @@
 # parallel make tries to run `mkdir -p a/b' and `mkdir -p a/c'
 # concurrently, both version can detect that a/ is missing, but only
 # one can create it and the other will error out.  Consequently we
-# restrict ourselves to GNU make (using the --version option ensures
+# restrict ourselves to GNU mkdir (using the --version option ensures
 # this.)
 AC_DEFUN([AM_PROG_MKDIR_P],
 [if mkdir -p --version . >/dev/null 2>&1 && test ! -d ./--version; then
-  # We used to keeping the `.' as first argument, in order to
+  # We used to define $(mkdir_p) as `mkdir -p -- .', in order to
   # allow $(mkdir_p) to be used without argument.  As in
   #   $(mkdir_p) $(somedir)
-  # where $(somedir) is conditionally defined.  However this is wrong
-  # for two reasons:
-  #  1. if the package is installed by a user who cannot write `.'
-  # make install will fail,
-  #  2. the above comment should most certainly read
-  # $(mkdir_p) $(DESTDIR)$(somedir)
-  # so it does not work when $(somedir) is undefined and
-  # $(DESTDIR) is not.
-  #  To support the latter case, we have to write
-  # test -z "$(somedir)" || $(mkdir_p) $(DESTDIR)$(somedir),
-  #  so the `.' trick is pointless.
+  # where $(somedir) is conditionally defined.  However we don't do
+  # that anymore.
+  #  1. before we restricted the check to GNU mkdir, `mkdir -p .' was
+  # reported to fail in read-only directories.  The system where this
+  # happened has been forgotten.
+  #  2. in practice we call $(mkdir_p) on directories such as
+  #   $(mkdir_p) "$(DESTDIR)$(somedir)"
+  # and we don't want to create $(DESTDIR) if $(somedir) is empty.
+  # To support the latter case, we have to write
+  #   test -z "$(somedir)" || $(mkdir_p) "$(DESTDIR)$(somedir)"
+  # so $(mkdir_p) always has an argument.
+  # We will have better chances of detecting a missing test if
+  # $(mkdir_p) complains about missing arguments.
+  #  3. $(mkdir_p) is named after `mkdir -p' and we don't expect this
+  # to accept no argument.
+  #  4. having something like `mkdir .' in the output is unsightly.
   mkdir_p='mkdir -p --'
 else
   # On NextStep and OpenStep, the `mkdir' command does not
   # recognize any option.  It will interpret all options as
-  # directories to create, and then abort because `.' already
-  # exists.
+  # directories to create.
   for d in ./-p ./--version;
   do
 test -d $d && rmdir $d

-- 
Alexandre Duret-Lutz

Re: "$(MAKE) %STAMP%" without $(AM_MAKEFLAGS)?

[Alexandre Duret-Lutz]

>>> "SK" == Stepan Kasal <[EMAIL PROTECTED]> writes:

 SK> Hello,
 SK> I have noticed the following:
 SK> file lib/am/remake-hdr.am  contains command

 SK> $(MAKE) %STAMP%

 SK> while I'd expect the usual $(MAKE) $(AM_MAKEFLAGS) %STAMP% for the
 SK> recursive call of make.

 SK> Similar with %DIRSTAMP% in texibuild.am and texi-vers.am .

 SK> Isn't this a bug?

Thanks.  I'm installing this on HEAD.

2005-08-07  Alexandre Duret-Lutz  <[EMAIL PROTECTED]>

* automake.in (lang_yacc_target_hook): Use AM_MAKEFLAGS in recursive
$(MAKE) invocations.
* lib/am/texibuild.am (?GENERIC_INFO?%SOURCE_SUFFIX%%DEST_SUFFIX%):
Likewise.
* lib/am/texi-vers.am (%STAMPVTI%): Likewise.
* lib/am/remake-hdr.am (%CONFIG_H%): Likewise.
* Makefile.am (maintainer-check): Check for this.
Report from Stepan Kasal.

Index: Makefile.am
===
RCS file: /cvs/automake/automake/Makefile.am,v
retrieving revision 1.240
diff -u -r1.240 Makefile.am
--- Makefile.am 19 Jul 2005 19:19:17 -  1.240
+++ Makefile.am 7 Aug 2005 08:27:11 -
@@ -2,7 +2,7 @@
 
 ## Makefile for Automake.
 
-## Copyright (C) 1995, 1996, 1997, 1998, 1999, 2001, 2002, 2003, 2004
+## Copyright (C) 1995, 1996, 1997, 1998, 1999, 2001, 2002, 2003, 2004, 2005
 ## Free Software Foundation, Inc.
 
 ## This program is free software; you can redistribute it and/or modify
@@ -184,6 +184,12 @@
  exit 1; \
fi
 ## Tests should never call make directly.
+   @if grep '^[^#].*(MAKE) ' $(srcdir)/lib/am/*.am $(srcdir)/automake.in |\
+   grep -v 'AM_MAKEFLAGS'; then \
+ echo 'Use $$(MAKE) $$(AM_MAKEFLAGS).' 1>&2; \
+ exit 1; \
+   fi
+## Tests should never call make directly.
@if grep -v '^#' $(srcdir)/tests/*.test | grep ':[  ]*make'; then \
  echo 'Do not run "make" in the above tests.  Use "$$MAKE" instead.' 
1>&2; \
  exit 1; \
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1609
diff -u -r1.1609 automake.in
--- automake.in 27 Jul 2005 11:09:45 -  1.1609
+++ automake.in 7 Aug 2005 08:27:12 -
@@ -5425,12 +5425,13 @@
  INTERNAL))
  {
my $condstr = $cond->subst_string;
-   $output_rules .= ("$condstr${header}: $output\n"
- # Recover from removal of $header
- . "[EMAIL PROTECTED] test ! -f \$@; then \\\n"
- . "$condstr\t  rm -f $output; \\\n"
- . "$condstr\t  \$(MAKE) $output; \\\n"
- . "$condstr\telse :; fi\n");
+   $output_rules .=
+ "$condstr${header}: $output\n"
+ # Recover from removal of $header
+ . "[EMAIL PROTECTED] test ! -f \$@; then \\\n"
+ . "$condstr\t  rm -f $output; \\\n"
+ . "$condstr\t  \$(MAKE) $(AM_MAKEFLAGS) $output; \\\n"
+ . "$condstr\telse :; fi\n";
  }
# Distribute the generated file, unless its .y source was
# listed in a nodist_ variable.  (&handle_source_transform
Index: lib/am/remake-hdr.am
===
RCS file: /cvs/automake/automake/lib/am/remake-hdr.am,v
retrieving revision 1.45
diff -u -r1.45 remake-hdr.am
--- lib/am/remake-hdr.am14 May 2005 20:28:53 -  1.45
+++ lib/am/remake-hdr.am7 Aug 2005 08:27:12 -
@@ -1,5 +1,5 @@
 ## automake - create Makefile.in from Makefile.am
-## Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2003, 2004
+## Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2003, 2004, 2005
 ## Free Software Foundation, Inc.
 
 ## This program is free software; you can redistribute it and/or modify
@@ -24,7 +24,7 @@
 ## Recover from removal of CONFIG_HEADER
@if test ! -f $@; then \
  rm -f %STAMP%; \
- $(MAKE) %STAMP%; \
+ $(MAKE) $(AM_MAKEFLAGS) %STAMP%; \
else :; fi
 
 
Index: lib/am/texi-vers.am
===
RCS file: /cvs/automake/automake/lib/am/texi-vers.am,v
retrieving revision 1.27
diff -u -r1.27 texi-vers.am
--- lib/am/texi-vers.am 14 May 2005 20:28:53 -  1.27
+++ lib/am/texi-vers.am 7 Aug 2005 08:27:12 -
@@ -1,6 +1,6 @@
 ## automake - create Makefile.in from Makefile.am
-## Copyright (C) 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002, 2003, 2004
-## Free Software Foundation, Inc.
+## Copyright (C) 1994, 1995, 1996, 1998, 1999,

Re: No AM_YFLAGS support within conditionals

[Alexandre Duret-Lutz]

>>> "JL" == Juergen Leising <[EMAIL PROTECTED]> writes:
[...]
 JL> src/libbsql/Makefile.am:8: automake does not support AM_YFLAGS
 JL> being defined conditionally
 JL> automake: 
 JL> automake: ## Internal Error ##
 JL> automake: 
 JL> automake: undefined condition `TRUE' for `AM_YFLAGS'
[...]

Thanks.  I'm installing this on HEAD.

2005-08-07  Alexandre Duret-Lutz  <[EMAIL PROTECTED]>

* lib/Automake/Variable.pm (variable_value): Do not read the TRUE
value of a conditionally defined variable.
Report from Juergen Leising.

Index: THANKS
===
RCS file: /cvs/automake/automake/THANKS,v
retrieving revision 1.274
diff -u -r1.274 THANKS
--- THANKS  9 Jul 2005 09:24:40 -   1.274
+++ THANKS  7 Aug 2005 09:54:24 -
@@ -125,6 +125,7 @@
 js pendry  [EMAIL PROTECTED]
 Juergen A. Erhard  [EMAIL PROTECTED]
 Juergen Keil   [EMAIL PROTECTED]
+Juergen Leising[EMAIL PROTECTED]
 Julien Sopena  [EMAIL PROTECTED]
 Karl Berry [EMAIL PROTECTED]
 Karl Heuer [EMAIL PROTECTED]
Index: lib/Automake/Variable.pm
===
RCS file: /cvs/automake/automake/lib/Automake/Variable.pm,v
retrieving revision 1.39
diff -u -r1.39 Variable.pm
--- lib/Automake/Variable.pm27 Jul 2005 11:09:45 -  1.39
+++ lib/Automake/Variable.pm7 Aug 2005 09:54:25 -
@@ -1180,7 +1180,7 @@
 
 Get the C value of a variable, warn if the variable is
 conditionally defined.  C<$var> can be either a variable name
-or a C instance (this allows to calls sucha
+or a C instance (this allows calls such
 as C<$var-Evariable_value>).
 
 =cut
@@ -1191,7 +1191,8 @@
 my $v = ref ($var) ? $var : var ($var);
 return () unless $v;
 $v->check_defined_unconditionally;
-return $v->rdef (TRUE)->value;
+my $d = $v->def (TRUE);
+    return $d ? $d->value : "";
 }
 
 =item C<$str = output_variables>

-- 
Alexandre Duret-Lutz

Re: Automake: Internal Error

[Alexandre Duret-Lutz]

>>> "RW" == Richard Warwick <[EMAIL PROTECTED]> writes:

 RW> When running autogen.sh for ethereal-0.10.12 on OpenBSD3.7
[...]
 RW> automake --add-missing --gnu
 RW> automake: 
 RW> automake: ## Internal Error ##
 RW> automake: 
 RW> automake: unrequested trace `include'
 RW> automake: Please contact .
 RW> at /usr/local/share/automake-1.9/Automake/Channels.pm line 562
 RW> Automake::Channels::msg('automake', '', 'unrequested trace 
 RW> `include\'') called at 

This is a bug of the OpenBSD ports.
http://lists.gnu.org/archive/html/automake/2005-06/msg00085.html
-- 
Alexandre Duret-Lutz

Shared books are happy books. http://www.bookcrossing.com/friend/gadl

Re: AM_PROG_CC_C_O assumption

[Alexandre Duret-Lutz]

Hi Ralf,

>>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:

 RW> CVS Automake assumes that, as soon as per-target compile flags are used,
 RW> AM_PROG_CC_C_O is necessary.

Not exactly : it assumes that AM_PROG_CC_C_O is necessary as
soon as -c and -o are used.  Automake has always used -c -o for
per-target compile flags as well as for subdir-objects, however
previous versions of Automake forgot to require AM_PROG_CC_C_O
in the former case (but did in the letter).

 RW> Strictly speaking, this assumption is
 RW> correct: automake can't tell that there won't be a clash in object file
 RW> names.  And the user shouldn't be able to know, since the mapping of
 RW> source file names to object file names is an undocumented internal.

 RW> However, in practice there are many Makefile.am's out there that use
 RW> target_CFLAGS and such, and will definitely never have name conflicts

This means we don't have to rename the objects file in all
cases.  I agree, but it's seem too hard to tell.  Since
currently Automake always uses -c -o in this case, the presence
or absence of conflicts isn't a justification against or for
AM_PROG_CC_C_O.

 RW> and/or never possibly be used by a losing compiler.  

Definitely.

 RW> And as such I think it is too harsh to have Automake fail
 RW> hard in this case; giving a warning would be sufficient
 RW> IMVHO.

OK, let's turn in into a portability warning.  And since
portability warnings have been waiting to be turned on for three
years now, let's do that too.  I'm installing the following two
patches.

 RW> For example, the modular Xorg tree would need hundreds of changes to get
 RW> working, most of them actually in Makefile.am's that build only one
 RW> object.  A failure due to Automake upgrade will be perceived as an
 RW> Automake regression.  (Nevertheless, I intend to bring this issue to
 RW> their attention, after hearing your opinion about it.)

I'm not sure why the changes need to be in Makefile.ams.  Why not add
AM_PROG_CC_C_O to configure.ac?


2006-03-10  Alexandre Duret-Lutz  <[EMAIL PROTECTED]>

* lib/Automake/ChannelDefs.pm: Make -Wportability the default in
gnu and gnits modes.
* doc/automake.texi (Invoking Automake): Adjust.

Index: NEWS
===
RCS file: /cvs/automake/automake/NEWS,v
retrieving revision 1.301
diff -u -r1.301 NEWS
--- NEWS29 Jan 2006 17:35:12 -  1.301
+++ NEWS10 Mar 2006 10:23:17 -
@@ -93,6 +93,10 @@
 that have been declared as programs in the same Makefile.
 This is mostly useful when some check_PROGRAMS are listed in TESTS.
 
+  - `-Wportability' has finally been turned on by default for `gnu' and
+`gnits' strictness.  This means automake will complain about %-rules
+or $(GNU Make functions) unless you switch to `foreign' strictness or
+use `-Wno-portability'.
 
 New in 1.9:
 
Index: doc/automake.texi
===
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.130
diff -u -r1.130 automake.texi
--- doc/automake.texi   21 Feb 2006 20:29:25 -  1.130
+++ doc/automake.texi   10 Mar 2006 10:23:20 -
@@ -1253,12 +1253,8 @@
 variables.
 
 The categories output by default are @samp{syntax} and
[EMAIL PROTECTED]  Additionally, @samp{gnu} is enabled in @option{--gnu} and
[EMAIL PROTECTED] strictness.
-
[EMAIL PROTECTED] warnings are currently disabled by default, but they
-will be enabled in @option{--gnu} and @option{--gnits} strictness in a
-future release.
[EMAIL PROTECTED]  Additionally, @samp{gnu} and @samp{portability}
+are enabled in @option{--gnu} and @option{--gnits} strictness.
 
 @vindex WARNINGS
 The environment variable @env{WARNINGS} can contain a comma separated
Index: lib/Automake/ChannelDefs.pm
===
RCS file: /cvs/automake/automake/lib/Automake/ChannelDefs.pm,v
retrieving revision 1.3
diff -u -r1.3 ChannelDefs.pm
--- lib/Automake/ChannelDefs.pm 14 May 2005 20:28:51 -  1.3
+++ lib/Automake/ChannelDefs.pm 10 Mar 2006 10:23:20 -
@@ -1,4 +1,4 @@
-# Copyright (C) 2002, 2003 Free Software Foundation, Inc.
+# Copyright (C) 2002, 2003, 2006 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
@@ -324,29 +324,12 @@
 {
   my ($name) = @_;
 
-  # FIXME: 'portability' warnings are currently disabled by default.
-  # Eventually we want to turn them on in GNU and GNITS modes, but
-  # we don't do this yet in Automake 1.7 to help the 1.6/1.7 transition.
-  #
-  # Indeed there would be only two ways to get rid of these new warnings:
-  #  1. adjusting M

Re: A release with LIBOBJDIR?

[Alexandre Duret-Lutz]

>>> "SK" == Stepan Kasal <[EMAIL PROTECTED]> writes:

 SK> current CVS versions of Autoconf and Automake use make variable
 SK> LIBOBJDIR, to enable using AC_LIBOBJ with non-recursive makefiles.

Among other uses.

 SK> But if we release versions with LIBOBJDIR, we will be bounded to
 SK> support it in future releases, even in case that it will become
 SK> redundant.

Let's worry when we get there.

[...]

 SK> It is often requested that AC_LIBOBJ should support more than one
 SK> libobj directory.  (Examples were presented which show how this
 SK> feature would make some projects more manageable.)

The need is to split required sources/objects into groups, for
instance to create different libraries.  Using multiple
directories is just one way to do it.

The plan discussed when LIBOBJDIR was introduced was to have
multiple LIBOBJS-like variables (and hence multiple LIBOBJDIR
variables), allowing you to build different libraries even if
all your sources are in the same directory.  This can be
introduced without breaking the existing LIBOBJS/LIBOBJDIR
interface.

 SK> I imagine that for each declared libobj subdirectory, Autoconf would
 SK> filter out everything but the objects from that directory.  And for
 SK> the top-level makefile, LIBOBJS would contain all the objects, with
 SK> their relative path.

What about non-recursive Makefiles that are not at the
top-level?  What about recursive Makefiles that uses @LIBOBJS@
from different directories directly without creating an archive?

 SK> As you can see, this would also solve the problemof non-recursive
 SK> makefiles, rendering LIBOBJDIR redundant.

I clearly don't think so :)
-- 
Alexandre Duret-Lutz

Shared books are happy books. http://www.bookcrossing.com/friend/gadl

Re: Problem with automake

[Alexandre Duret-Lutz]

| autoconf --version: 2.57  automake --verison: 1.6.3 

These releases are like 4-year old, btw.
-- 
Alexandre Duret-Lutz

Shared books are happy books. http://www.bookcrossing.com/friend/gadl

Re: Multiply distributed files

[Alexandre Duret-Lutz]

>>> "AD" == Akim Demaille <[EMAIL PROTECTED]> writes:

 AD> So the "dist" immediately below is executed with a read-only source
 AD> tree.  This seems wrong to me, I suggest restoring the rights first.

Why?  We ought to be able to run "make dist" from an up-to-date
read-only source tree.  Removing these rights ensures this.
Restoring them would hide some bugs, like people modifying source
files during "make dist".

Maybe a less invasive change is to restore the rights only on the
directories that have been copied with `cp -p'? (I think this can be
done immediately after the `cp -p'.)

IMHO EXTRA_DISTing directories should be only used for directories
that are generated automatically (e.g., Doxygen documentation).  If
the directory contains hand-maintained files (and hence backups, etc.),
EXTRA_DISTing it is too error-prone.  
-- 
Alexandre Duret-Lutz

Shared books are happy books. http://www.bookcrossing.com/friend/gadl

Re: automake-1.9 internal error

[Alexandre Duret-Lutz]

Hi Kim,

>>> "KH" == Kim Højgaard-Hansen <[EMAIL PROTECTED]> writes:

[...]
 KH> automake-1.9: unrequested trace `'
[...]
 KH> The system is OpenBSD-3.8 stable

Can you see this error with the same package on another system ?

On OpenBSD, the trace errors are usually due to the implementation of M4 used.
Autoconf requires GNU m4, but the OpenBSD folks have hacked it to use
OpenBSD M4 instead.  This yields some corner cases problems (however those
I remember involve the M4 macro "include", which is not the case here).

I suggest you reconfigure Autoconf to use GNU M4 if that's easy,
or simply reinstall these two package from their GNU sources.

(In case you wonder why I'm not mentioning Automake, here
Automake is calling Autoconf which is in turn calling M4 in
"trace mode".)

-- 
Alexandre Duret-Lutz

Shared books are happy books. http://www.bookcrossing.com/friend/gadl

Re: automake crash

[Alexandre Duret-Lutz]

>>> "BW" == Bas Wijnen <[EMAIL PROTECTED]> writes:

 BW> Hi,

 BW> automake just crashed on me, and it told me to send a mail
 BW> here, so I do. :-)

Hi Bas, thanks for doing so.

 BW> This is what it says:
 BW> Makefile.am:184: unterminated conditionals: DEBUGGING_TRUE DEPRECATION_TRUE

This means Automake's parser is completely lost. Automake is not
smart enough to handle conditionals inside multi-lines
definitions.

You shouldn't use :

 BW> console_cflags = \
 BW> if WARNINGS
 BW> @EXTRA_WARNING_FLAGS@ \
 BW> -Wall \
 BW> -W \
 BW> -Wpointer-arith \
 BW> -Wcast-qual \
 BW> -Wwrite-strings \
 BW> -Wno-sign-compare \
 BW> -Waggregate-return \
 BW> -Wstrict-prototypes \
 BW> -Wmissing-prototypes \
 BW> -Wmissing-declarations \
 BW> -Wredundant-decls \
 BW> -Wnested-externs \
 BW> -O \
 BW> endif
 BW> if DEBUGGING
 BW> -ggdb3 \
 BW> endif
 BW> if DEPRECATION
 BW> -DG_DISABLE_DEPRECATED \
 BW> endif
 BW> -I$(top_srcdir)/common \
 BW> -I$(top_builddir)/common \
 BW> -I$(includedir) \
 BW> $(GLIB2_CFLAGS)

but rather something like

| if WARNINGS
| warnings_console_cflags = @EXTRA_WARNING_FLAGS@ \
|   -Wall \
|   -W \
|   -Wpointer-arith \
|   -Wcast-qual \
|   -Wwrite-strings \
|   -Wno-sign-compare \
|   -Waggregate-return \
|   -Wstrict-prototypes \
|   -Wmissing-prototypes \
|   -Wmissing-declarations \
|   -Wredundant-decls \
|   -Wnested-externs \
|   -O
| endif
| if DEBUGGING
| debugging_console_cflags = -ggdb3
| endif
| if DEPRECATION
| deprecation_console_cflags = -DG_DISABLE_DEPRECATED 
| endif
| 
| console_cflags = $(warnings_console_cflags) $(debugging_console_cflags) \
|   $(deprecation_console_cflags) \
|   -I$(top_srcdir)/common \
|   -I$(top_builddir)/common \
|   -I$(includedir) \
|   $(aGLIB2_CFLAGS)

or you can build console_cflags bits after bits :

| console_cflags =
| if WARNINGS
| console_cflags += @EXTRA_WARNING_FLAGS@ \
|   -Wall \
|   -W \
|   -Wpointer-arith \
|   -Wcast-qual \
|   -Wwrite-strings \
|   -Wno-sign-compare \
|   -Waggregate-return \
|   -Wstrict-prototypes \
|   -Wmissing-prototypes \
|   -Wmissing-declarations \
|   -Wredundant-decls \
|   -Wnested-externs \
|   -O
| endif
| if DEBUGGING
| console_cflags += -ggdb3
| endif
| if DEPRECATION
| console_cflags += -DG_DISABLE_DEPRECATED 
| endif
| console_cflags += -I$(top_srcdir)/common \
|   -I$(top_builddir)/common \
|   -I$(includedir) \
|   $(aGLIB2_CFLAGS)


Fixing Automake to diagnose this situation would be difficult.
I'll just mention it in the manual.

 BW> automake-1.9: 
 BW> automake-1.9: ## Internal Error ##
 BW> automake-1.9: 
 BW> automake-1.9: undefined condition `TRUE' for `AUTOMAKE_OPTIONS'

Automake is so lost it thinks AUTOMAKE_OPTIONS is conditionally defined.
This error message at least is easily improved.

 BW> # Pioneers - Implementation of the excellent Settlers of Catan board game.
 BW> #   Go buy a copy.

I own one already.  Great game !

I'm checking the following patch in.

2006-08-04  Alexandre Duret-Lutz  <[EMAIL PROTECTED]>

* doc/automake.texi (Conditionals): Split in two sections, "Usage"
and "Portability", and add a third one, "Limits" to explain how
conditional definitions inside multi-lines definitions can be
handled.
* automake.in (handle_options): Do not assume that
AUTOMAKE_OPTIONS is defined in TRUE, but diagnose conditional
definitions of AUTOMAKE_OPTIONS.
Report from Bas Wijnen.
* tests/amopt.test: New test.
* tests/Makefile.am (TESTS): Add it.

Index: THANKS
===
RCS file: /cvs/automake/automake/THANKS,v
retrieving revision 1.286
diff -u -r1.286 THANKS
--- THANKS  24 Jun 2006 05:35:43 -  1.286
+++ THANKS  4 Aug 2006 10:21:46 -
@@ -23,6 +23,7 @@
 Art Haas   [EMAIL PROTECTED]
 Assar Westerlund   [EMAIL PROTECTED]
 Axel Belinfante[EMAIL PROTECTED]
+Bas Wijnen [EMAIL PROTECTED]
 Bernard Giroud [EMAIL PROTECTED]
 Bernard Urban  [EMAIL PROTECTED]
 Bernd Jendrissek   [EMAIL PROTECTED]
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1624
diff -u -r1.1624 automake.in
--- automake.in 4 Aug 2006 06:08:58 -   1.1624
+++ automake.in 4 Aug 2006 10:21:46 -
@@ -1055,12 +1055,16 @@
   my $var = var ('AUTOMAKE_OPTIONS');
   if ($var)
 {
-  # FIXME: We should disallow conditional definitions of AUTOMAKE_OPTIONS.
-  if (process_option_list ($var->rdef (TRUE)->location,
-  $var->value_as_list_recursive (cond_filter =>
-  

Re: Mltiple target rules not recognized

[Alexandre Duret-Lutz]

>>> "SK" == Stepan Kasal <[EMAIL PROTECTED]> writes:

 SK> install uninstall installcheck:
 SK> : Do not run $@ in elfutils.

 SK> But automake did not notice that the rule redefines a standard rule.

Yes.  This is also known as FIXME #3 in the parser...
-- 
Alexandre Duret-Lutz

Shared books are happy books. http://www.bookcrossing.com/friend/gadl

Re: pointless automake error about libtool libraries

[Alexandre Duret-Lutz]

>>> "BH" == Bruno Haible <[EMAIL PROTECTED]> writes:

[...]

 BH> and indeed for linking to not-installed libraries no -rpath
 BH> option is needed.

More precisely: noinst_LTLIBRARIES *requires* that no -rpath be
given.  (We're talking about Libtool's -rpath option here.)
noinst_LTLIBRARIES is used to declare convenience Libtool
libraries, and the absence of -rpath is the only way to tell
Libtool to build a convenience library and later use it as such.

This error points out a real conflict.  You can't ask the same
file to be built in two different ways, for two different purposes.

[...]

-- 
Alexandre Duret-Lutz

Shared books are happy books. http://www.bookcrossing.com/friend/gadl

Re: suggest making de-ANSI-fication obsolete; also, "an hello" -> "a hello"

[Alexandre Duret-Lutz]

>>> "PE" == Paul Eggert <[EMAIL PROTECTED]> writes:

 PE> -  - Automake installs an "Hello World!" example package in $(docdir).
 PE> +  - AM_C_PROTOTYPES and ansi2knr are now documented as being obsolete.
 PE> +They still work in this release, but may be withdrawn in a future one.
 PE> +
 PE> +  - Automake installs a "Hello World!" example package in $(docdir).
 PE> This example is used thorough the new "Autotools Introduction"
 PE> chapter of the manual.

Thanks!  I've installed this, and also fixed
s/thorough/throughout/ while I was at it.
-- 
Alexandre Duret-Lutz

Shared books are happy books. http://www.bookcrossing.com/friend/gadl

Re: is -Wportability enabled by default?

[Alexandre Duret-Lutz]

>>> "BH" == Bruno Haible <[EMAIL PROTECTED]> writes:

[...]

 BH> "Warning categories include:
 BH> ...
 BH> `portability'   portability issues
 BH> `syntax'dubious syntactic constructs (default)
 BH> `unsupported'   unsupported or incomplete features (default)
 BH> `all'   all the warnings
 BH> ...
 BH> "
 BH> which appears to say that -Wportability needs to be enabled explicitly?

Good catch!  I'm checking this in.

2006-08-23  Alexandre Duret-Lutz  <[EMAIL PROTECTED]>

* lib/Automake/ChannelDefs.pm (usage): Mention that -Wportability
is enabled by default with gnu and gnits strictness.
Report from Bruno Haible.

Index: lib/Automake/ChannelDefs.pm
===
RCS file: /cvs/automake/automake/lib/Automake/ChannelDefs.pm,v
retrieving revision 1.4
diff -u -r1.4 ChannelDefs.pm
--- lib/Automake/ChannelDefs.pm 10 Mar 2006 10:51:37 -  1.4
+++ lib/Automake/ChannelDefs.pm 23 Aug 2006 19:19:49 -
@@ -168,7 +168,7 @@
   `gnu'   GNU coding standards (default in gnu and gnits modes)
   `obsolete'  obsolete features or constructions
   `override'  user redefinitions of Automake rules or variables
-  `portability'   portability issues
+  `portability'   portability issues (default in gnu and gnits modes)
   `syntax'dubious syntactic constructs (default)
   `unsupported'   unsupported or incomplete features (default)
   `all'   all the warnings


-- 
Alexandre Duret-Lutz

Shared books are happy books. http://www.bookcrossing.com/friend/gadl

Re: CPPASCOMPILE doesn't use $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES)

[Alexandre Duret-Lutz]

>>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:

[...]

 RW> 2006-10-14  Ralf Wildenhues  <[EMAIL PROTECTED]>

 RW> * automake.in: For preprocessed assembler, add `$(DEFS)
 RW> $(DEFAULT_INCLUDES) $(INCLUDES)' to the compile rule.
 RW> * doc/automake.texi (Assembly Support): Update.
 RW> * NEWS: Update.
 RW> Suggested by Thomas Schwinge and Ralf Corsepius.

Please go ahead, but do not forget to update THANKS.
-- 
Alexandre Duret-Lutz

Shared books are happy books. http://www.bookcrossing.com/friend/gadl

Re: ftp.gnu.org no longer working with old method?

[Alexandre Duret-Lutz]

I had the same problem while releasing Automake 1.10 tonight.
A new version of gnupload is in Automake's CVS (and attached).
-- 
Alexandre Duret-Lutz

Shared books are happy books. http://www.bookcrossing.com/friend/gadl
#!/bin/sh
# Sign files and upload them.

scriptversion=2006-10-15.21

# Copyright (C) 2004, 2005, 2006  Free Software Foundation
#
# 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, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
# 02110-1301, USA.

# Originally written by Alexandre Duret-Lutz <[EMAIL PROTECTED]>.

set -e

GPG='/usr/bin/gpg --batch --no-tty'
to=

usage="Usage: $0 [OPTIONS]... FILES...

Sign all FILES, and upload them to selected destinations.

Options:
  --help   print this help text and exit
  --to DESTspecify one destination for FILES
   (multiple --to options are allowed)
  --user NAME  sign with key NAME
  --versionoutput version information and exit

Recognized destinations are:
  alpha.gnu.org:DIRECTORY
  savannah.gnu.org:DIRECTORY
  savannah.nongnu.org:DIRECTORY
  ftp.gnu.org:DIRECTORY
   build directive files and upload files by FTP
  [EMAIL PROTECTED]:DIRECTORYupload files with scp

Example:
  gnupload --to sources.redhat.com:~ftp/pub/automake \\
   --to alpha.gnu.org:automake \\
   automake-1.8.2b.tar.gz automake-1.8.2b.tar.bz2

Report bugs to .
Send patches to ."

while test -n "$1"; do
  case $1 in
--help)
  echo "$usage"
  exit $?
  ;;
--to)
  if test -z "$2"; then
echo "$0: Missing argument for --to" 1>&2
exit 1
  else
to="$to $2"
shift 2
  fi
  ;;
--user)
  if test -z "$2"; then
echo "$0: Missing argument for --user" 1>&2
exit 1
  else
GPG="$GPG --local-user $2"
shift 2
  fi
  ;;
--version)
  echo "gnupload $scriptversion"
  exit $?
  ;;
-*)
  echo "$0: Unknown option \`$1', try \`$0 --help'" 1>&2
  exit 1
  ;;
*)
  break
  ;;
  esac
done

if test $# = 0; then
  echo "$0: No file to upload" 1>&2
  exit 1
else
  :
fi

# Make sure all files exist.  We don't want to ask
# for the passphrase if the script will fail.
for file;
do
  if test ! -f $file; then
echo "$0: Cannot find \`$file'" 1>&2
exit 1
  else
:
  fi
done

# Make sure passphrase is not exported in the environment.
unset passphrase

# Reset PATH to be sure that echo is a built-in.  We will later use
# `echo $passphrase' to output the passphrase, so it is important that
# it is a built-in (third-party programs tend to appear in `ps'
# listings with their arguments...).
# Remember this script runs with `set -e', so if echo is not built-in
# it will exit now.
PATH=/empty echo -n "Enter GPG passphrase: "
stty -echo
read -r passphrase
stty echo
echo

for file;
do
  echo "Signing $file..."
  rm -f $file.sig
  echo $passphrase | $GPG --passphrase-fd 0 -ba -o $file.sig $file
done

for dest in $to;
do
  for file;
  do
echo "Uploading $file to $dest..."
files="$file $file.sig"
destdir=`echo $dest | sed 's/[^:]*://'`
case $dest in
  alpha.gnu.org:*)
rm -f $file.directive $file.directive.asc
cat >$file.directive<$file.directive<

Re: ftp.gnu.org no longer working with old method?

[Alexandre Duret-Lutz]

>>> "PE" == Paul Eggert <[EMAIL PROTECTED]> writes:

 PE> Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
 >> A new version of gnupload is in Automake's CVS (and attached).

 PE> Thanks, but it's not in Automake's CVS yet.  Did you have second
 PE> thoughts?

I was making too many things at the same time and forgot to run
clcommit and send the patch.

It's now done.

2006-10-16  Alexandre Duret-Lutz  <[EMAIL PROTECTED]>

* lib/gnupload: Update to version 1.1 of directive file.

Index: lib/gnupload
===
RCS file: /cvs/automake/automake/lib/gnupload,v
retrieving revision 1.7
diff -u -r1.7 gnupload
--- lib/gnupload13 May 2006 17:53:38 -  1.7
+++ lib/gnupload15 Oct 2006 19:36:46 -
@@ -1,7 +1,7 @@
 #!/bin/sh
 # Sign files and upload them.
 
-scriptversion=2006-05-11.09
+scriptversion=2006-10-15.21
 
 # Copyright (C) 2004, 2005, 2006  Free Software Foundation
 #
@@ -143,14 +143,22 @@
 case $dest in
   alpha.gnu.org:*)
rm -f $file.directive $file.directive.asc
-   echo directory: $destdir >$file.directive
+   cat >$file.directive<$file.directive
+   cat >$file.directive<http://www.bookcrossing.com/friend/gadl

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

[Alexandre Duret-Lutz]

Hi!

I have a project that contains 8 different test-suites, each in its
own directory.  Some test suite are big, other are small, but they
test different parts of the project and I like being able to run "make
check" in the relevant directory.  They are run sequentially (with
SUBDIRS) when "make check" is run from the top-level.

I upgraded to Automake 1.12.1 to discover the each of these test-suite
now displays a huge summary like:


Testsuite summary for spot 0.9.1a

# TOTAL: 2
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


Instead of the older one-line summary I'm used too.

I can live with the extra verbosity, but I find the initial header
saying "Testsuite summary for spot 0.9.1a" in each of the test suites
very confusing.  The above in definitely *not* a testsuite summary for
the project, it's only a test summary for one directory.

I think the easiest fix would be to change the header to just
"Testsuite summary", without mentioning the package.

Another option could be to let the test-suite be named in Makefile.am.
Maybe introduce
TESTS_DISPLAY_NAME = $(PACKAGE_STRING)
and use
echo "Testsuite summary for $(TESTS_DISPLAY_NAME)"
so that people with multiple test-suites can give them different names.

-- 
Alexandre Duret-Lutz

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

[Alexandre Duret-Lutz]

Hi,

This perl warning occurs with automake 1.16.2 (but is much older) when
TEST_EXTENSIONS is set to the empty string (I don't want to remove
extensions before appending .log) and EXEEXT is defined.

% cat configure.ac
AC_INIT([foo],[1.0])
AM_INIT_AUTOMAKE([foreign])
AC_PROG_CC  dnl comment this line to make the warning disappear
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
% cat Makefile.am
TEST_EXTENSIONS =
LOG_COMPILER = echo
TESTS = foo.test
% touch foo.test
% autoreconf -fi
configure.ac:3: installing './compile'
configure.ac:2: installing './install-sh'
configure.ac:2: installing './missing'
Use of uninitialized value in string eq at /usr/bin/automake line 4953.
parallel-tests: installing './test-driver'
% nl -ba `command -v automake` | sed -n '4951,4955p'
  4951if ($handle_exeext)
  4952  {
  4953unshift (@test_suffixes, $at_exeext)
  4954  unless $test_suffixes[0] eq $at_exeext;
  4955  }

-- 
Alexandre Duret-Lutz