mailing list handling (was: My project can't use `silent-rules')
Hi Bob, all, * Bob Friesenhahn wrote on Sun, May 17, 2009 at 10:43:51PM CEST: P.S. I am pretty pissed that almost all recent discussion of automake major features and direction has apparently taken place on the automake-patches list rather than the automake list where it belongs. Not everyone interested in Automake has time to read all the bugs and detailed patches. It seems not easy to please you. :-) A while ago you (IMHO rightfully) complained about too much email coming your way, with duplicates due to cross-posting to more than one mailing list increasing the pressure even more. I can only assume that at that time, you were subscribed to the -patches and/or bug- lists as well. Now, we try to keep cross posts to a reasonable low, esp. I try to push people to move to the -patches list when patches are involved, thinking that the plain automake list also has many readers that aren't primarily interested in the development of new features. However, as you now noted that has a drawback too: some of the feature discussion moves away from the automake list. Ping-ponging back and forth between both lists during the course of one message thread seems awkward and error-prone, too. I understand nothing is black and white here; also, the situation is a bit remedied with cross posts as the mailing list manager allows to only receive one mail per cross post. I do not know of a perfect solution to the general problem though. Of course I can suggest that if you are interested in details of new features, then it cannot hurt to also read the -patches list. But maybe now that your immediate problem is solved, you aren't all that pissed any more anyway. ;-) Cheers, Ralf
Re: My project can't use `silent-rules'
Hi Bob, On 5/17/2009 11:05 PM, Bob Friesenhahn wrote: On Mon, 18 May 2009, Ralf Wildenhues wrote: You can use AM_SILENT_RULES Worked! Thanks! Unfortunately, it does not silence the warnings from my code. Forgive me, but do you really want it to do this? Of course, if you want to permanently silence warnings from your code, you should probably just use appropriate pragmas or command-line options to disable those warnings. One of the primary reasons (IMHO) for Automake silent rules is so that I CAN see the warnings in my code (without resorting to redirecting make's stdout to /dev/null, that is). At least, that's one reason why, for several years now, I've advocated an Autotools option for silent builds. Regards, John
My project can't use `silent-rules'
I see that the only way to request the new `silent-rules' feature is by using the new form of AM_INIT_AUTOMAKE to pass the option. Since my package can not use the new form of AM_INIT_AUTOMAKE, then it can not request `silent-rules'. The reason for this limitation is that using the new form of AM_INIT_AUTOMAKE also requires using the new form of AC_INIT. Since my package can not use the new form of AC_INIT, then it can not use the new form of AM_INIT_AUTOMAKE and therefore can not request `silent-rules'. The reason why my package can not use AC_INIT is that the package version information is (often) computed by shell script code based on the last entry in the project ChangeLog or other information. It is (apparently) not possible for user-provided script code to be executed prior to AC_INIT and it is not clear if AC_INIT would allow passing a shell variable in order to obtain the package version value. Several other files in my project include content from the package version. It does not make sense to manually edit configure.ac each time a new package needs to be produced. Is there a way that some of my own script code can be executed prior to AC_INIT and a way to pass this information in a shell variable to AC_INIT? If so, then I can move ahead, but otherwise I am forced to ignore these major updates to Automake. Please advise. Bob P.S. I am pretty pissed that almost all recent discussion of automake major features and direction has apparently taken place on the automake-patches list rather than the automake list where it belongs. Not everyone interested in Automake has time to read all the bugs and detailed patches. -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: My project can't use `silent-rules'
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes: The reason why my package can not use AC_INIT is that the package version information is (often) computed by shell script code based on the last entry in the project ChangeLog or other information. It is (apparently) not possible for user-provided script code to be executed prior to AC_INIT and it is not clear if AC_INIT would allow passing a shell variable in order to obtain the package version value. == configure.ac == m4_include([version.m4]) AC_PREREQ([2.61]) AC_PROG_CC AC_PROG_INSTALL AC_OUTPUT == version.m4 == AC_INIT([foo], [1.0], [...@stanford.edu]) Seems to work for me, although I've not used it for a real package. You then just automatically generate version.m4 as part of your bootstrap process before running autoconf. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: My project can't use `silent-rules'
On Sun, 2009-05-17 at 15:43 -0500, Bob Friesenhahn wrote: The reason why my package can not use AC_INIT is that the package version information is (often) computed by shell script code based on the last entry in the project ChangeLog or other information. It is (apparently) not possible for user-provided script code to be executed prior to AC_INIT and it is not clear if AC_INIT would allow passing a shell variable in order to obtain the package version value. This isn't necessarily an answer, but its a step towards one. I've recently started using the following consistently in my projects - I got tired of repeating version numbers as hard coded strings in multiple places. AC_DEFUN([FOO_MAJOR_VERSION], [0]) AC_DEFUN([FOO_MINOR_VERSION], [0]) AC_DEFUN([FOO_MICRO_VERSION], [1]) AC_DEFUN([FOO_VERSION], [FOO_MAJOR_VERSION.FOO_MINOR_VERSION.FOO_MICRO_VERSION]) AC_PREREQ([2.59]) AC_INIT([libfoo], [FOO_VERSION], [liboo-de...@example.com]) AC_CONFIG_SRCDIR([foo/foo.h.in]) AM_INIT_AUTOMAKE([-Wall -Werror foreign subdir-objects]) AC_CONFIG_MACRO_DIR([m4]) [FOO_MAJOR_VERSION]=FOO_MAJOR_VERSION [FOO_MINOR_VERSION]=FOO_MINOR_VERSION [FOO_MICRO_VERSION]=FOO_MICRO_VERSION [FOO_VERSION]=FOO_VERSION AC_SUBST([FOO_MAJOR_VERSION]) AC_SUBST([FOO_MINOR_VERSION]) AC_SUBST([FOO_MICRO_VERSION]) AC_SUBST([FOO_VERSION]) Its pretty verbose, when I get some more time to fiddle with build systems rather than writing code I'm going to look at reducing the redundancy - it should be one line for each FOO_VARIABLE. Anyhow, the key thing is that defining FOO_VARIABLE as a function lets you do pretty much what you want. -Rob -- signature.asc Description: This is a digitally signed message part
Re: My project can't use `silent-rules'
On Sun, May 17, 2009 at 4:43 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: I see that the only way to request the new `silent-rules' feature is by using the new form of AM_INIT_AUTOMAKE to pass the option. Since my package can not use the new form of AM_INIT_AUTOMAKE, then it can not request `silent-rules'. As I understand it, there are several ways to turn that option on, only one of which is via AM_INIT_AUTOMAKE. Can you just use one of the other methods?
Re: My project can't use `silent-rules'
Bob Friesenhahn wrote: It does not make sense to manually edit configure.ac each time a new package needs to be produced. Is there a way that some of my own script code can be executed prior to AC_INIT and a way to pass this information in a shell variable to AC_INIT? If so, then I can move ahead, but otherwise I am forced to ignore these major updates to Automake. Please advise. 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]), [bug-autoc...@gnu.org]) Peter -- Peter O'Gorman http://pogma.com
Re: My project can't use `silent-rules'
On Sun, 17 May 2009, NightStrike wrote: On Sun, May 17, 2009 at 4:43 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: I see that the only way to request the new `silent-rules' feature is by using the new form of AM_INIT_AUTOMAKE to pass the option. Since my package can not use the new form of AM_INIT_AUTOMAKE, then it can not request `silent-rules'. As I understand it, there are several ways to turn that option on, only one of which is via AM_INIT_AUTOMAKE. Can you just use one of the other methods? It turns out that `silent-rules' does not work via the other methods as previous Automake options did. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: My project can't use `silent-rules'
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]), [bug-autoc...@gnu.org]) 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 configure.ac 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 -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: My project can't use `silent-rules'
On Sun, 17 May 2009, Bob Friesenhahn wrote:
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.
As further clarification of execute configure script shell code,
this is how I execute an exernal script at the moment to obtain
package version (as well as shared library versioning).
AC_INIT(magick/magick.h)
. ${srcdir}/version.sh
AM_INIT_AUTOMAKE($PACKAGE_NAME,${PACKAGE_VERSION}${PACKAGE_VERSION_ADDENDUM},
' ')
The package name, version, tarball naming, and shared library
versioning information all come from this external script. All
working fine since late 2002.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: My project can't use `silent-rules'
Hi Bob, * Bob Friesenhahn wrote on Sun, May 17, 2009 at 10:43:51PM CEST: I see that the only way to request the new `silent-rules' feature is by using the new form of AM_INIT_AUTOMAKE to pass the option. Since my package can not use the new form of AM_INIT_AUTOMAKE, then it can not request `silent-rules'. You can use AM_SILENT_RULES instead. Cheers, Ralf
