[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: My project can't use `silent-rules'

From: Bob Friesenhahn
Subject: Re: My project can't use `silent-rules'
Date: Sun, 17 May 2009 19:48:39 -0500 (CDT)

On Sun, 17 May 2009, Peter O'Gorman wrote:
Hi Bob,
You can use m4_easycmd to run your scripts at autoconf time. E.g. (from
autoconf itself):
AC_INIT([GNU Autoconf],
       m4_esyscmd([build-aux/git-version-gen .tarball-version]),

I still owe you large quantities of beer. However, in order to clarify, I would like to be able to execute configure script shell script code (more like a configure test) and not generate a new configure script just because the version has changed.

It turns out that the current approach is just an artifact of how things have been done since day one. The reality is that the configure script does not care more about package version (or name, etc.) any more than any other data that the configure script figures out. It just needs a way to readily produce the information for informational messages.

A proper solution would allow the configure script to determine the version via user provided shell code. For example, the libtiff package includes the file VERSION yet the person doing the release always needs to remember to make sure that the VERSION file and the number in are in sync. As long as the makefile includes rules to cover any added dependency relationships, then there is no problem.

For GraphicsMagick "daily" snapshots, my shell code creates a snapshot date based on the most recent ChangeLog entry and this is used as part of the version. The generated configure script never gets updated unless functionality has been changed.

If m4_esyscmd can be mentioned here, can a user-provided macro (which invokes shell code) be invoked from the same place?

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]