Re: [Automake-NG] [PATCH 6/7] [ng] dist: new API to specify formats of distribution tarballs

[Stefano Lattarini]

On 08/13/2012 05:49 PM, Bob Friesenhahn wrote:
> On Mon, 13 Aug 2012, Stefano Lattarini wrote:
>>>
>> Note that my set of patches doesn't yet offer any public API for
>> the addition of new distribution format; but the new form of the
>> codebase should at least make that very easy to add (it's mostly
>> a matter of changing the name of few so far internal-only
>> variables, and adding the proper documentation).
> 
> What I would expect is that the developer can include a makefile
> fragment which adds a target expressed in a well-documented way,
>
The issue with APIs that work merely adding "targets" is that, while
GNU make is capable of advanced "reflection" about make variables (the
$(.VARIABLES) macro, the $(origin ...) function, etc) it sorely lacks
it for targets.

So, rather than targets, I was thinking about simple variables; for
example, this is (more or less) how the compression format '.xz' and
the archive format '.zip' are defined in Automake's own internals:

  am.dist.all-formats += xz
  am.dist.ext.xz = tar.xz
  am.dist.compress-cmd.xz = XZ_OPT=$${XZ_OPT--e} xz -c
  am.dist.uncompress-cmd.xz = xz -dc

  am.dist.all-formats += zip
  am.dist.ext.zip = zip
  # We don't simply compress a tar archive, so we need to give
  # commands to define an archive starting from the distdir:
  am.dist.create-cmd.zip = zip -rq $(distdir).zip $(distdir)
  am.dist.extract-cmd.zip = unzip $(distdir).zip

So, this is what you could conceivably do if you wanted to distribute
uncompressed tar archives:

  am.dist.all-formats += plain
  am.dist.ext.plain = tar
  am.dist.compress-cmd.plain = cat
  am.dist.uncompress-cmd.plain = cat

And this is what you could do if you wanted to re-introduce support
for gzip-compressed shar archives:

  am.dist.all-formats += shar
  am.dist.ext.zip = shar.gz
  # We don't simply compress a tar archive, so we need to give
  # commands to define an archive starting from the distdir:
  am.dist.create-cmd.zip = \
    shar $(distdir) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).shar.gz
  am.dist.extract-cmd.zip = \
    GZIP=$(GZIP_ENV) gzip -dc $(distdir).shar.gz | unshar

> and likely by cloning/modifying an already-working target. This
> target is then brought in by being referenced.
>
This would require putting yet more logic at automake runtime, and this
is a behaviour Automake-NG wants to move away from, preferring to have
as much logic as possible at make runtime instead.

>>> For example, my project also wants to be able to produce 'srpm'
>>> format as well as a '7z' format.
>>>
>> That could be a nice test bed for the API, if you want to become
>> an early Automake-NG adopter ;-)
> 
> While I can see GraphicsMagick moving to Automake-NG,
>
But alas, not before we've worked out the issue with the obsolete
two-arguments invocation of AM_INIT_AUTOMAKE, which GraphicsMagick
relies on, but which has been removed from Automake-NG.  Have you
managed to write a detailed bug report for that already?

> it could only do that in a fork
>
Of course, I thought that was implied.  We wouldn't want a mature,
stable software like GraphicsMagick to rely on an experimental one
like Automake-NG!

> (in Mercurial or maybe git mirror)
>
The latter would be swell ;-)

> until Automake-NG is stable and properly released.
> 
> Bob

Thanks,
  Stefano