dailydebs-team team mailing list archive

[James Westby <jw+debian@xxxxxxxxxxxxxxx>]

On Wed Sep 02 19:21:10 +0100 2009 Michael Terry wrote:
> EXTRACTDIR is just a tmpdir created by my script.  It could be anything;
> it could be generated on the fly.  Just an implementation detail to
> store the extracted files for a second until they're moved back into
> $PWD.

Yeah, sorry, I should have read it in context. It is still fragile,
but as your recipes don't exist outside of your script that's not
a problem for you.

> > In your example I'm not sure what would be done by "make dist" that
> > wouldn't be done by "make c" or whatever. Going through the tarball
> > seems to be an unncessary step there.
> 
> I'm not sure what you mean by "make c".  You were giving an example
> target ala "make all"?

Yeah, whatever target makes all the .c files from the Vala files.

> One difference is that is not unusual for projects to have dist hooks
> and special handling for the dist target.  It's good for testing that
> you are correctly distributing all needed files and such.  In short,
> it's nice to have one path for consumable code, so there are no
> surprises when you do eventually run 'make dist' at release time.

That's a fair point. My intimation was that you could just to everything
up to the tarball step, and you would have everything you would get
from untarring the tarball. That may obviously not be possible with
the architecture of autotools though, and other systems may be even
less likely to adhere to this. It would be good if you could have
a "make distcheck" that did the checks but not the "dist."

I see your arguments, but I'm still unsure of how we could implement
it in a generic way. For example, how do we know what file "make
dist" will create to untar? It seems we would need to know the following
things:

   * What command to run
   * File that will be created (glob pattern?)
   * How to get back to a directory full of files (it may be a directory
     that is created, this could be a heuristic for most things)

While I dislike get-orig-source, something in that vein would perhaps
be useful for this.

Thanks,

James