automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Troubles with pkgdata_DATA primary...


From: Stepan Kasal
Subject: Re: Troubles with pkgdata_DATA primary...
Date: Wed, 18 Jun 2008 19:09:48 +0200
User-agent: Mutt/1.5.17 (2007-11-01)

Hello,

On Wed, Jun 18, 2008 at 10:42:10AM -0600, John Calcote wrote:
> Never mind ... duh ... I forgot to take the docs directory out of the
> EXTRA_DIST variable when I added it to the SUBDIRS variable.
> 
> Thus (I'm guessing) the distdir code was trying to create files that
> were already in place, and marked read-only by the distcheck code.

indeed.  The test performed bu distcheck looks like this:
make dist # to create the tarball
distdir=ftk-1.1
# unpack the tarball
chmod -R a-w $(distdir); chmod a+w $(distdir)
mkdir ftk-1.1/_build && cd ftk-1.1/_build
../configure
# ...
make dist

So you are doing a "make distdir" with a VPATH build (i.e., with
build tree != source tree) and the source tree is flagged readonly.

And this does not sometimes work if EXTRA_DIST contains a directory,
see below for technical details.

Please note that Automake manual discourages distributing a whole
directory---instead, all regular files should be listed in
Makefile.am.  (Yes, I know this limitation is not always convenient.)

Now the technical details:

During "make distdir", all to-be-distributed files are collected and
copied to a separate tree.  If a file is present in the build tree,
it is taken from there; otherwise, it is taken from the source tree.

But if there is a directory in the EXTRA_DIST variable and that
directory is present in both trees, then "make distdir" has to call
"cp -pR" for both, to merge the content of both trees.

In the above scenario, the source tree is _flagged_ read-only, and
that flag is copied to distdir.  If the two trees overlap, and the
same file comes from build tree, then it cannot overwrite the
read-only flagged one, and "make distdir" fails.

When I think about it, I recognize that this crash does not reflect a
real world problem (in real world, the source tree is read-only
because it is mounted read-only, not because it is _flagged_
read-only), so it is a bug in distcheck, which should be fixed
somehow...  Let me think...   Stay tuned.

Have a nice day,
        Stepan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]