Re: How do users use autoconf-archive?

[Francesco Salvestrini]

Hi Dustin,

On Saturday 18 July 2009, Dustin J. Mitchell wrote:
> Personally, I've been just downloading macros with 'wget' -- I
> wouldn't have ever thought to download a tarball, and checking out the
> CVS or git repositories was not worth the trouble.

I too, I've an 'update' target which downloads things here and there. I should 
admit even those from gnulib at the moment, but that's due to copy&paste and 
my laziness ...

> Gnulib provides a nice example, though.  As all of you probably know,
> gnulib does not do "releases" per se -- to use gnulib you download the
> entire repo using git (I assume there's some non-git way to do this,
> too - maybe a nightly archive).  Then you run 'gnulib-tool',
> specifying the list of modules you'd like installed in your package.
> This has the advantage of being able to process its own dependencies,
> detect conflicts, etc.
>
> This is nice for the user, too -- to upgrade your gnulib (e.g., on
> trunk after branching for a release), just re-run the gnulib-tool
> command and commit the results.  You don't have to carry around any
> more files from gnulib than those which are used by the project.  Now
> that gnulib has grown so large, this is quite a boon.
>
> In the autoconf-archive case, such a scheme has the added advantage of
> being able to warn users of functionality changes and other potential
> gotchas *before* the cause problems down the road.  This is
> particularly key for autoconf macros, since developers may not see
> them break until they make a release and a user on AIX or Cygwin
> complains.
>
> I (obviously) like this model a lot, but I'm open to alternatives.  I
> think we should have a defined process for including autoconf-archive
> in a project, though.  What are your thoughts?

I like the approach and I think we should use a slightly modified one maybe:

1) Have an aatool script
2) Have the aarchive autoconfiscated

1 -> aatool would follow what you stated and mimics (somewhat) the gnulib 
approach: a --dry-run option, license check and so on. The script should run 
out-of-the-box as in gnulib

2 -> In order to provide:
2.1 the usual 'install' target (for those who are acquainted)
2.2 the facilities for the info generation and installation
2.3 a simpler way to handle (and check all the required tools) for maintenance 
purposes

The wget capability remains: download the text blob from the git/cgit web 
interface as usual.

Best regards,
Francesco

-- 
The meek don't want it.