[Top][All Lists]

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

Re: distcheck: permission denied for file created from .PHONY target

From: Marko Lindqvist
Subject: Re: distcheck: permission denied for file created from .PHONY target
Date: Sun, 15 Mar 2015 10:27:43 +0200

On 14 March 2015 at 10:13, Marko Lindqvist <address@hidden> wrote:
>  Do you have any advice for the following situation:
>  I have a generated file I want to distribute in the tarball, so it's
> listed in EXTRA_DIST.
>  The file can get outdated (i.e. you can't rely it being always
> correct even when it exist), but the exact situation where it gets
> outdated would be hard to track (having it to have correct
> dependencies would be *the* clean solution to my problems) so it's set
> as .PHONY target.
>  As for normal 'make' (file does not get generated) and 'make dist'
> (file always gets (re)generated and put to tarball) this works
> perfectly. However, this causes 'make distcheck' to fail as it tries
> to regenerate the file to the directory where the write permissions
> have been turned off.

 I think I managed to work around this. The machinery got quite
complex, so I still need to test it more, but basically:
 - I generate the file as temporary file inside builddir, where we
always have write permissions
 - Then I compare the temporary file and one currently in srcdir (if
there is one), and move temporary file over only if they differ

 This means that there's no attempt to write (copy) to srcdir when the
regenerated file is identical to old one. This should always be the
case when doing 'make distcheck', and having the srcdir without write
permissions. If not, that would indicate problem in some other part of
my build process (otherwise identical tree should result in identical
generated file). Obviously I can never add anything like timestamp of
the latest generation to the file while relying on this method.

 And if someone wonder why I don't simply let the file live in
builddir, that seems not to be supported for files belonging to
tarball (and quite logically so, they would anyway end to srcdir when
the tarball is extracted)

 - ML

reply via email to

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