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

[Greg A. Woods]

[ On , May 13, 2002 at 22:49:09 (+0200), Alexandre Duret-Lutz wrote: ]
> Subject: Re: "make distcheck" vs. EXTRA_DIST files made during "make dist"
>
> >>> "Greg" == Greg A Woods <address@hidden> writes:
> 
>  Greg> [ On Monday, May 13, 2002 at 10:26:56 (+0200), Alexandre Duret-Lutz 
> wrote: ]
> 
> [...]
> 
>  >> Because these distributed files are dependent upon
>  >> non-distributed built files.
> 
>  Greg> They _are_ the built files.  That my Makefile goes through two steps to
>  Greg> create them is irrellevant.  They must be created during "make dist",
>  Greg> just like the "configure" script itself.  They are dependent upon
>  Greg> distributed files but they themselves must also be distributed.
> 
> Huh?  AFAICT the distributed newsyslog.cat8-dist depends on
> newsyslog.cat8 which is *not* distributed (this one is
> built). Likewise for the other *-dist files.

I believe my *-dist files are only an example of the larger issue, but
all the same that my proposed fix is the best generic solution.

Potentially any product file which is derived from a source file, and
which must be included in the distribution, and thus which must _not_ be
removed by "make distclean" is could cause the same problem.  In some
cases the dependency might be on config.status, while in others it might
be on another built file (or both, as is the case with my *-dist files).

I understand what you mean by strictly saying these final EXTRA_DIST
files depend on files which are not distributed, but the same is true of
config.status and obviously it must not be distributed at all, and
ultimately any dependency on config.status is only a way to represent
the recording of "configure-time" environmental dependencies in a way
that 'make' can understand.



> If newsyslog.cat8 was distributed we would never have seen this
> problem (because newsyslog.cat8 would not be built during
> distcheck, and hence the rule to rebuild newsyslog.cat8-dist
> would not be triggered).  But before you jump on this statement:
> I have understood you don't want do this! :) I'm just trying to
> explain how all these issues (Texinfo's, Autogen's, and yours)
> are instances of the *same* problem:
>   
> << distributed files dependent upon non-distributed built files >>

Whether or not the final product file depends on an intermediate product
file or not is really irrelevant.

Indeed that's why I suggest the other projects may be able to take the
same benefit from my elegant little proposed fix.  There may be a little
leap of logic, or at least a new perspective, necessary though.....

>  >> 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.
> 
>  Greg> No, I don't think so.  Distribution directories can be read-only.  They
>  Greg> must not ever be modified during a VPATH reach-over build.  Indeed 
> isn't
>  Greg> that exactly the case with "make distcheck"?
> 
> We are talking about different things.  What I call
> `distribution directory', $(distdir), is the temporary directory
> into which files are copied before making the tarball.  This one
> is obviously writable, and you can modify it right before the
> tarball is made using the `dist-hook' target as I suggested in
> the previous mail.
> 
> What you are talking about is the the source directory,
> $(srcdir), which indeed can be read-only when building in VPATH
> from a CD-ROM, or during `make distcheck'.


Ultimately my only complaint is with "make distcheck", so strictly
you're talking about a fix that won't work to fix the problem I'm
actually encountering (though the other hack you suggest in this most
recent message would likely work).  If I didn't find value in "make
distcheck" I would have no problem at all!  :-)


> I must say find the dist-hook approach much less ugly.

I'm sorry to say that I think they're all quite ugly!  ;-)


>  Greg> this is exactly the kind of feature that would make it
>  Greg> worth my while to do so).  However given the known
>  Greg> commonality of this problem I would strongly suggest that
>  Greg> the Automake maintainers should choose one of the options
>  Greg> I've offered so that everyone has a common solution
>  Greg> available out-of-the-box.
> 
> Personally I'm not really against introducing yet another
> variable, I just think it doesn't help in the other cases.  
> A solution which is generic enough to address the whole issue
> would be better.  (This said, I have nothing to suggest.)

It'll take more thinking than I have time for at the moment to check to
be sure my proposal can satisfy the needs of the other projects you've
noted.  Perhaps one of their authors will see a way before I get time to
look further.....

-- 
                                                                Greg A. Woods

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