On Sat, 23 Jan 2021, Zack Weinberg wrote:
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.
I thought so to. While developing GraphicsMagick, I use a different
versioning scheme (append a date to the version) and use the ChangeLog
file as the master for the date. But the ChangeLog file might be
edited several times in a day without the "version" changing. After
the second edit, there are problems. The problem becomes obvious just
by touching the ChangeLog file.
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.
It is definitely related to make's limitations, but also due to what
Autotools does.
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
I did try this type of solution. As I recall, it did not help because
the terminal target is Automake's regeneration rules, which are
apparently optimized to not modify the target files (e.g. configure)
if there was no change. Since the target was never updated, the rule
runs again.
The solution I thought was working was based on real file timestamps,
(which I thought would be robust) but it is not since Autotools does
not update the timestamp on the file it would regenerate.
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.
A tiny fork/exec is not a big deal. What becomes annoying is when it
is continually recurring because the Autotool's regeneration rule
never updated a target. I would rather face the cost of running
configure again (once) due to a time-stamp change than every time make
is executed.
When it is apparently decided that configure may need to be
regenerated, it goes and does something, but apparently decides that
nothing has changed so it can skip updating the output. Therefore,
the retries are perpetual until configure does get regenerated.
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}"],
[' '])
Well, that is interesting.
I have some memory that shell code in configure.ac which is provided
prior to AC_INIT is ignored and is not output to configure. If my
memory is correct, then accepting shell variables would be a major
change since AC_INIT would not be the start of everything.
I discovered that the AC_INIT with arguments is much more rigid and
unyielding than using environment variables. Due to this, I had to
make changes to other files because my interim version scheme does not
intend to change things like installation directories.
I may well persue this some more, but not in the main-line development
code that some OS distributions like Debian have started using like
normal releases. It is better for a side project.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
