[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why do I need both AC_INIT and AM_INIT_AUTOMAKE???
From: |
Bob Proulx |
Subject: |
Re: Why do I need both AC_INIT and AM_INIT_AUTOMAKE??? |
Date: |
Tue, 8 Apr 2003 11:04:49 -0600 |
User-agent: |
Mutt/1.3.28i |
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