Re: PATCH + What might cause this failure?

[Bruce Korb <bkorb at veritas dot com>]

Alexandre Duret-Lutz wrote:

>  Bruce> Oh, PacBell seems to be eating my emails

This is over now, but I'll need to resubscribe to automake....

>  Bruce> So, here it [the patch] is:
> 
> Where?

:-)  I got to writing and left off the patch.
Actually, even more absent minded, I was looking
at the autoconf archive and wondering where my
automake patch went  :-}.  Oops.  Anyway it was
in the archive:

  http://mail.gnu.org/pipermail/automake/2002-August/011696.html

> I'm not sure I understand what you want to do, but this last
> statement sounds very odd.  Why don't you simply use DIST_SUBDIRS?

Because:

1.  It is only mentioned in two paragraphs buried deep in the doc.
    I wasn't searching in a way that brought me to those two paragraphs.
2.  Even now that I've read it, using it would mean taking over
    an automatable chore from automake.
3.  It won't solve the problem anyway.  Here's the code in question:

 ## source files _and_ generated files.  It is also important when the
 ## directory exists only in $(srcdir), because some vendor Make (such
 ## as Tru64) will magically create an empty directory in `.'
            if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
              cp -pR $(srcdir)/$$file $(distdir)$$dir || exit 1; \
            fi; \
            cp -pR $$d/$$file $(distdir)$$dir || exit 1; \
          else \

The problem is that the "$(srcdir)/$$file" has been made read-only for
"make distcheck".  Since the permissions are copied, the result is
read-only, too.  Then, when the "$$d/$$file" files are copied, the
copy fails and "exit 1" is invoked.  Oops.  My solution was to tolerate
copy failures, since it didn't make any difference.  A better fix is
to add back write permissions after the first (conditional) copy.