Hi Bob, I managed to find your old message about "dynamically computing
package versions for Automake and Autoconf". Some initial comments
follows. I'm adding the Autoconf list in CC:, because I believe this
is an Autoconf issue more than an Automake one.
On 05/20/2012 12:59 AM, Bob Friesenhahn wrote:
> Stefano,
>
> This change will cause significant issues for GraphicsMagick unless there is a workaround:
>
> - Support for the two- and three-arguments invocation forms of the
> AM_INIT_AUTOMAKE macro will be deprecated in the next minor version
> of Automake (1.12.1) and removed in the next major version (1.13).
>
> GraphicsMagick invokes it like
>
> AM_INIT_AUTOMAKE($PACKAGE_NAME,"${PACKAGE_VERSION}${PACKAGE_VERSION_ADDENDUM}", ' ')
>
> The reason is because it avoids needing to edit configure.ac (a really stupid
> practice)
>
I agree with this; with today's DVCS, it's very tempting (and IMHO useful)
to base a package's version number on the current revision number/SHA-1; so
that the version is bound to change with every commit, and forcing a full
re-autotooling + reconfiguration + rebuild of the package for every commit
sounds just crazy.
But then, I believe this is something that should to be fixed at the Autoconf
level. I.e., the version number shouldn't be hard-coded in the generated
configure and config.status scripts, nor put in 'config.h' or other generated
headers -- or at least, we should be able to tell Autoconf not do that, and
how to fetch/define/compute the version number at runtime instead.
> every time a new release tarball will be cut. Instead the version information
> to apply is computed by a script which is sourced by configure.
>
> What is the workaround for this?
>
Actually, it depends. Where and why do you use such dynamically-computed
version number in exactly?
Thanks,
Stefano
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
