On Sat, Jan 23, 2021 at 11:38 AM Bob Friesenhahn
<bfriesen@xxxxxxxxxxxxxxxxxxx> wrote:
>
> I am about to give up on using the new style AC_INIT in the form of
>
> AC_INIT(m4_esyscmd([./version.sh packagename]),
> m4_esyscmd([./version.sh packageversion]),
> m4_esyscmd([./version.sh packagebugreport]),
> m4_esyscmd([./version.sh packagetarname]),
> m4_esyscmd([./version.sh packageurl]))
>
> and the "new" single-argument form of AM_INIT_AUTOMAKE.
>
> Although I have spent a couple of days trying to get this approach to
> work, no combination of dependency declarations, stamp files, etc.,
> has resulted in success.
I’m sorry this has been such a frustrating experience for you, and I’m
also sorry I didn’t react to this thread earlier. I thought you had
already found an approach that _did_ work for you.
If I understand your problem correctly, it’s fundamentally a
limitation in Make itself: there’s no way to tell Make to pay
attention to a file’s _contents_, as well as its timestamp, when
deciding whether targets that depend on that file are out of date.
There’s not a whole lot the Autotools can do about that limitation,
but I do know some workarounds that might suit.
First, there _is_ a general-purpose workaround for this limitation in
Make. It’s ugly and you may not like it, but it’s battle-tested in
e.g. GCC’s Makefiles. It looks like this:
# some versions of `touch` do not correctly set the timestamp
STAMP = echo timestamp >
build/gencondmd.c: s-conditions; @true
s-conditions: $(MD_DEPS) build/genconditions$(build_exeext)
$(RUN_GEN) build/genconditions$(build_exeext) $(md_file) > tmp-condmd.c
$(SHELL) $(srcdir)/../move-if-change tmp-condmd.c build/gencondmd.c
$(STAMP) s-conditions
The rule whose target is ‘s-conditions’ lists the actual dependencies
of ‘build/gencondmd.c’, but it uses a helper script ‘move-if-change’
to ensure that the timestamp on ‘build/gencondmd.c’ only changes when
its contents actually change. Therefore, targets that depend on
gencondmd.c are not rebuilt unnecessarily.
The ‘build/gencondmd.c: s-conditions’ rule does get run every time you
type ‘make’ while ‘s-conditions’ has a timestamp newer than
‘build/gencondmd.c’, which is why that rule’s commands are ‘@true’ --
do nothing and print nothing. It does fork and exec one shell per
rule of this form; as far as I know there is no way to do better.
There is a long comment elaborating on this explanation in GCC’s
Makefile: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/Makefile.in;hb=HEAD#l1859
If that doesn’t suit, the Automake manual specifically calls out the
way GraphicsMagick is currently invoking AM_INIT_AUTOMAKE as a thing
you _can’t_ do with arguments to AC_INIT:
| …differently from what happens for AC_INIT invocations, this
| AM_INIT_AUTOMAKE invocation supports shell variables’ expansions in
| the PACKAGE and VERSION arguments (which otherwise defaults,
| respectively, to the PACKAGE_TARNAME and PACKAGE_VERSION defined via
| the AC_INIT invocation; see The AC_INIT macro in The Autoconf
| Manual); and this can still be useful in some selected
| situations. Our hope is that future Autoconf versions will improve
| their support for package versions defined dynamically at configure
| runtime; when (and if) this happens, support for the two-args
| AM_INIT_AUTOMAKE invocation will likely be removed from Automake.
So I think you are actually safe continuing to use AM_INIT_AUTOMAKE
with two arguments that are shell variable expansions, the way you’re
doing it now, and ignoring the -Wobsolete warning. I am not sure how
I have managed never to notice this note before now. I’ve filed
https://savannah.gnu.org/support/index.php?110431 saying that AC_INIT
should start accepting shell variables in its arguments. I’m not sure
what other consequences this may have, but you can make aclocal and
automake shut up about AC_INIT by passing a dummy version argument:
AC_INIT([GraphicsMagick], [DUMMY-VERSION-NUMBER])
. ${srcdir}/version.sh
AM_INIT_AUTOMAKE(
[$PACKAGE_NAME],
["${PACKAGE_VERSION}${PACKAGE_VERSION_ADDENDUM}"],
[' '])
zw
