Re: Why do I need both AC_INIT and AM_INIT_AUTOMAKE???

[Bob Proulx]

Alexandre Duret-Lutz wrote:
> Bob Proulx writes:
> > AC_INIT(configure.ac)
> > AM_INIT_AUTOMAKE(atlc,4.2.12)
> 
> Please no.  As the manual you quote explains, the above syntax is
> being phased out.  Use the following instead.
> 
>  AC_INIT([atlc], [4.2.12], address@hidden)
>  AM_INIT_AUTOMAKE

Thank you for the correction.

I just looked at the docs for 1.7.3 and the following was in the
example section.  This is in the code 'Complete' in the examples
section showing a hello world program.  It was an earlier search hit
than the later documentation an confirmed my legacy use of these.  I
just searched, found the hit, and moved on since this is the way I
expected it to be.

     dnl Process this file with autoconf to produce a configure script.
     AC_INIT(src/hello.c)
     AM_INIT_AUTOMAKE(hello, 1.3.11)

Looking specifically for this now in the manual I do see the
following.  I am going to quote the entire section.  It would get too
confusing to take little bits out of the context.

> `AM_INIT_AUTOMAKE([OPTIONS])'
> `AM_INIT_AUTOMAKE(PACKAGE, VERSION, [NO-DEFINE])'
>      Runs many macros required for proper operation of the generated
>      Makefiles.
> 
>      This macro has two forms, the second of which has two required
>      arguments: the package and the version number.  This latter form is
>      obsolete because the PACKAGE and VERSION can be obtained from
>      Autoconf's `AC_INIT' macro (which itself has an old and a new
>      form).
> 
>      If your `configure.in' has:
>           AC_INIT(src/foo.c)
>           AM_INIT_AUTOMAKE(mumble, 1.5)
>      you can modernize it as follow:
>           AC_INIT(mumble, 1.5)
>           AC_CONFIG_SRCDIR(src/foo.c)
>           AM_INIT_AUTOMAKE
> 
>      Note that if you're upgrading your `configure.in' from an earlier
>      version of Automake, it is not always correct to simply move the
>      package and version arguments from `AM_INIT_AUTOMAKE' directly to
>      `AC_INIT', as in the example above.  The first argument of
>      `AC_INIT' is the name of your package (e.g. `GNU Automake'), not
>      the tarball name (e.g. `automake') you used to pass to
>      `AM_INIT_AUTOMAKE'.  Autoconf's rule to derive a tarball name from
>      the package name should work for most but not all packages.
>      Especially, if your tarball name is not all lower case, you will
>      have to use the four-argument form of `AC_INIT' (supported in
>      Autoconf versions greater than 2.52g).
> 
>      When `AM_INIT_AUTOMAKE' is called with a single argument, it is
>      interpreted as a space-separated list of Automake options which
>      should be applied to every `Makefile.am' in the tree.  The effect
>      is as if each option were listed in `AUTOMAKE_OPTIONS'.
> 
>      By default this macro `AC_DEFINE''s `PACKAGE' and `VERSION'.  This
>      can be avoided by passing the `no-define' option, as in:
>           AM_INIT_AUTOMAKE([gnits 1.5 no-define dist-bzip2])
>      or by passing a third non-empty argument to the obsolete form.

If I had actually read this section in depth I would have known about
this change.  Sorry.  Reading your reaction leads me to suggest that
the wording here is not strong enough.  I had not noticed it in my
casual perusal.  I suggest it say that use of the older syntax is
deprecated.  It would be nice if there were a section on upgrading
from previous versions of the autotools to newer versions.  A
checklist of changes to be made to track the updated syntax.

Thanks
Bob