Re: "make distcheck" vs. EXTRA_DIST files made during "make dist"

[Greg A. Woods]

[ On Monday, May 13, 2002 at 10:26:56 (+0200), Alexandre Duret-Lutz wrote: ]
> Subject: Re: "make distcheck" vs. EXTRA_DIST files made during "make dist"
>
> | > So, why are your files rebuilt at all?  
> | 
> | Because they must be.  :-)
> 
> Because these distributed files are dependent upon
> non-distributed built files.

They _are_ the built files.  That my Makefile goes through two steps to
create them is irrellevant.  They must be created during "make dist",
just like the "configure" script itself.  They are dependent upon
distributed files but they themselves must also be distributed.

However unlike the "configure" script I cannot remove them with "make
distclean" since they are not locally modifiable and they are intended
for use by people who have no hope of ever reproducing them.  (well
that's a slight exaggeration, but for many real-world users, not that
much different from the way they see their reality, and indeed this one
issue has generated more end-user e-mail than any of the real bugs in my
code have ever done for this project!)

Note also that though it might appear that my *-dist files are just
copies of built files, that's not quite true.  They are copies of
product files created using a very specific configuration.  They are not
expected to ever be modified by any third-party developer (unless he or
she creates their own indepndent release), and they are not expected to
be identical to product files derived from the same sources by users
capable of building the given sources.  They are more like templates
that are capable of standing in for the true product files in those rare
situations where the end user is truly unable to build their own locally
configured product files.

> | In general I can't believe this isn't a more frequent problem.  
> 
> Indeed.  A few other people have reported similar (if not worse)
> issues.  Well, at least I remember two projects (Texinfo and
> Autogen) which are in this case:
>  
>   - they distribute some files (the documentation) which are
>     created using the tool they build;
> 
>   - these generated files are explicitely marked as dependent 
>     upon the tool (to enforce proper ordering of the builds
>     when they don't exist).
> 
> Like in your case, distributed files are dependent upon
> non-distributed built files.  Except that here it causes
> unecessary and systematic rebuilds on the user side (this
> happens at `make'-time, not only `make dist').

Although I'm not intimately familiar with those two examples, I believe
in both cases they could use the approach I've taken to eliminate the
need to re-build distributed files at "make all" time and instead only
do it at "make dist" time as I do.  If so then those projects would also
benefit from the simple little enhancement I proposed.

> | (I'll also bet there'll be quite a few more developers besides myself
> | who get surprised by the apparent decision in 1.6 to not remove auto*
> | generated files with "make maintainer-clean".)
> 
> (This comes from the GNU Coding Standards.)

Indeed, but just because some standards author dreampt it up doesn't
mean it's right.  The premise this requirement is based on is
fundamentally flawed.  The very notion that a project maintainer could
possibly earn that title without having full use of all the tools used
in maintaining the project is absurd.

(The only headache those project maintainers with multiple projects face
w.r.t. the GNU Auto* tools is that there are too many incompatible
different versions of each of them!  :-)

> In your case I think a workaround would be to create your files
> during `make dist' but directly in the *distribution* directory,
> not in the source directory.

No, I don't think so.  Distribution directories can be read-only.  They
must not ever be modified during a VPATH reach-over build.  Indeed isn't
that exactly the case with "make distcheck"?

I'm very happy with the fix I proposed, and I think I would be equally
happy with changing the "make distclean" call to "make maintainer-clean".
(though I've not actually tested the latter)

I'm quite capable of maintaining and using my own Automake release (I've
certainly done so before and though I wouldn't exactly be happy to have
to do so again, this is exactly the kind of feature that would make it
worth my while to do so).  However given the known commonality of this
problem I would strongly suggest that the Automake maintainers should
choose one of the options I've offered so that everyone has a common
solution available out-of-the-box.

-- 
                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>