Re: rebuild texinfo menus
Yes, thanks, that looks good; please install.
rebuild texinfo menus
OK?
Thanks,
Ralf
2011-02-06 Ralf Wildenhues ralf.wildenh...@gmx.de
* doc/autoconf.texi: Rebuild menus using emacs ^C ^U ^A.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 1fbb7ad..232ed81 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -340,7 +340,7 @@ Top
* Preset Output Variables:: Output variables that are always set
* Installation Directory Variables:: Other preset output variables
-* Changed Directory Variables:: Warnings about @file{datarootdir}
+* Changed Directory Variables:: Warnings about @file{datarootdir}
* Build Directories:: Supporting multiple concurrent compiles
* Automatic Remaking:: Makefile rules for configuring
@@ -452,13 +452,6 @@ Top
* Programming in M4sugar:: Convenient pure M4 macros
* Debugging via autom4te:: Figuring out what M4 was doing
-Programming in M4sh
-
-* Common Shell Constructs:: Portability layer for common shell constructs
-* Polymorphic Variables:: Support for indirect variable names
-* Initialization Macros:: Macros to establish a sane shell environment
-* File Descriptor Macros:: File descriptor macros for input and output
-
M4 Quotation
* Active Characters:: Characters that change the behavior of M4
@@ -488,6 +481,13 @@ Top
* Set manipulation Macros:: Set manipulation in M4
* Forbidden Patterns:: Catching unexpanded macros
+Programming in M4sh
+
+* Common Shell Constructs:: Portability layer for common shell constructs
+* Polymorphic Variables:: Support for indirect variable names
+* Initialization Macros:: Macros to establish a sane shell environment
+* File Descriptor Macros:: File descriptor macros for input and output
+
Writing Autoconf Macros
* Macro Definitions:: Basic format of an Autoconf macro
@@ -562,6 +562,14 @@ Top
* Floating Point Portability:: Portable floating-point arithmetic
* Exiting Portably::Exiting and the exit status
+Integer Overflow
+
+* Integer Overflow Basics:: Why integer overflow is a problem
+* Signed Overflow Examples::Examples of code assuming wraparound
+* Optimization and Wraparound:: Optimizations that break uses of wraparound
+* Signed Overflow Advice:: Practical advice for signed overflow issues
+* Signed Integer Division:: @code{INT_MIN / -1} and @code{INT_MIN % -1}
+
Manual Configuration
* Specifying Target Triplets:: Specifying target triplets
@@ -2410,7 +2418,7 @@ Makefile Substitutions
@menu
* Preset Output Variables:: Output variables that are always set
* Installation Directory Variables:: Other preset output variables
-* Changed Directory Variables:: Warnings about @file{datarootdir}
+* Changed Directory Variables:: Warnings about @file{datarootdir}
* Build Directories:: Supporting multiple concurrent compiles
* Automatic Remaking:: Makefile rules for configuring
@end menu
@@ -20445,11 +20453,11 @@ Integer Overflow
behavior that is commonly not implemented.
@menu
-* Integer Overflow Basics:: Why integer overflow is a problem
-* Signed Overflow Examples:: Examples of code assuming wraparound
+* Integer Overflow Basics:: Why integer overflow is a problem
+* Signed Overflow Examples::Examples of code assuming wraparound
* Optimization and Wraparound:: Optimizations that break uses of wraparound
-* Signed Overflow Advice:: Practical advice for signed overflow issues
-* Signed Integer Division:: @code{INT_MIN / -1} and @code{INT_MIN % -1}
+* Signed Overflow Advice:: Practical advice for signed overflow issues
+* Signed Integer Division:: @code{INT_MIN / -1} and @code{INT_MIN % -1}
@end menu
@node Integer Overflow Basics
Re: configure -C by default?
At Sun, 6 Feb 2011 23:11:43 +0100, Ralf Wildenhues wrote: Back then, the consensus was to not make it the default because that was deemed too dangerous for users. Various reports are cited, and also the problem is mentioned that such kinds of failures tend to be quiet very often and are hard to debug. The reports are convincing for me that it would be bad to revive the old behaviour. Most of the GNU maintainers at FOSDEM didn't know about the -C option though. Maybe it would help to publicise -C in the output so people are more aware of it. e.g. $ ./configure configure: not caching test results (use -C to enable) checking for a BSD-compatible install... /usr/bin/install -c ... The message could be suppressed if config.status does not exist, so it's only shown if someone is configuring more than once. -- Brian Gough ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: configure -C by default?
On Mon, 7 Feb 2011, Ralf Corsepius wrote: The only real world use-case I currently have for config.caches, is it being a offering a crude way to override configure settings when configure guesses things wrong (A real-world use case: Paths to tools when cross-building scripts) My real world use-case is TeX live with a total of about 70 configure scripts and a very large number of common tests. Here -C gives a considerable speed-up with prcatically no problems. Thus I'd certainly object to a removal of the cache file. Regards Peter Breitenlohner p...@mppmu.mpg.de ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: configure -C by default?
On 02/07/2011 12:39 PM, Peter Rosin wrote: Den 2011-02-07 11:12 skrev Ralf Corsepius: On 02/07/2011 10:02 AM, Peter Rosin wrote: Den 2011-02-07 09:14 skrev Ralf Corsepius: Provided how HW has developed since the discussions from 10 years ago, you cited about, I am actually leaning towards proposing the converse of your proposal: Autoconf toconsider to abandoning config.cache. No, it still needs to be optional. I don't have anything against this. However, it's simply that the overwhelming majority of current packages hasn't been developed with config.caches in mind. And of those which really use it (complex packages such as GCC or GDB) occasionally to get things wrong. So, IMO, the advantage you believe to see on cygwin or mingw is of limited benefit. What do you mean by believe to see and of limited benefit? When you apply config.caches across packages, there is no guarantee that the values stored in a config.cache have the same semantics/meaning. I.e. when trying to share config.caches between packages (esp. independently developed ones), * you are at risk of _silently_ miscompiling something. * not to gain much, because a configure-script doesn't not honor config.caches (Pretty typical for modern configure script using non-standard macros). These were the aspects I was referring to. You are apparently not getting it, or you are downplaying my use case deliberately. Neither - I am using autoconf for many, many years and am well aware about the benefits config.cache can have, when _carefully_ being used. However, in contemporary development on todays, I've rare experienced config-caches to be more of a nuissance but to be of real advantage. The advantage I see for the packages I care about and regularly work on is very real: the experience moves from the pain in the ass category to bearable when I enable the cache. I'm not talking about one-time builds on Cygwin, I talking about doing development there. Well, I would not want to use Cygwin ;) Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: configure -C by default?
Den 2011-02-07 09:14 skrev Ralf Corsepius: Provided how HW has developed since the discussions from 10 years ago, you cited about, I am actually leaning towards proposing the converse of your proposal: Autoconf toconsider to abandoning config.cache. No, it still needs to be optional. Not everybody have the luxury of running on the bare OS. E.g. Cygwin is not very fast at running configure and that matters a lot for me since I have a number of packages with checks for about the same things and they benefit *very* much from sharing the cache. Cheers, Peter ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: configure -C by default?
On 07/02/11 23:45, Brian Gough wrote: At Sun, 6 Feb 2011 23:11:43 +0100, Ralf Wildenhues wrote: Back then, the consensus was to not make it the default because that was deemed too dangerous for users. Various reports are cited, and also the problem is mentioned that such kinds of failures tend to be quiet very often and are hard to debug. The reports are convincing for me that it would be bad to revive the old behaviour. Most of the GNU maintainers at FOSDEM didn't know about the -C option though. Maybe it would help to publicise -C in the output so people are more aware of it. e.g. $ ./configure configure: not caching test results (use -C to enable) checking for a BSD-compatible install... /usr/bin/install -c ... The message could be suppressed if config.status does not exist, so it's only shown if someone is configuring more than once. If you compile/install a program successfully, then apt-get remove a library (or stuff gets uninstalled when installing something else), then the manually compiled program doesn't run. A new ./configure will run successfully from the cached results even though a required library is missing. Seems pretty bad to me if using cached results is the default. Only developers doing repeated ./configure need it, and can just use the -C option. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Update GTK+ autotools configuration
Hello, I'm trying to update the GTK+ autotools configuration [1] (comments welcomed ;)). Also, I'd like to use the autoupdate program to verify that all the macros are updated but I get this error with current gtk master $ autoupdate /usr/bin/m4:/tmp/aukvr57a/input.m4:717: ERROR: end of file in string autoupdate: /usr/bin/m4 failed with exit status: 1 Any idea about how to solve this? Thanks, [1] https://bugzilla.gnome.org/show_bug.cgi?id=641640 -- Javier Jardón Cabezas ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: configure -C by default?
On 02/06/2011 11:11 PM, Ralf Wildenhues wrote: Apparently, a lot of users do not even know about configure -C aka. --config-cache which of course doesn't help Autoconf's reputation about producing configure scripts which are slow even for development. So one question would be what about making -C the default? I am opposed to it. We could have --force or --no-cache to turn it off. This behavior actually used to be the default. It was reverted around commit 5ae14bc8c048ed9a2dda6b67794ba (and also see commit 4abad4e9bfbcedd018302059844f8), 10 years ago. Here's some discussion from back then, listed in the order in which I traced back things, that is, the last thread has the most info: http://sourceware.org/ml/autoconf-patches/2000-04/msg0.html http://sourceware.org/ml/autoconf-patches/2000-03/msg00274.html http://sourceware.org/ml/autoconf/2000-02/msg00271.html Back then, the consensus was to not make it the default because that was deemed too dangerous for users. IMO, all what had been said 10+ years ago still applies. Besides that, config.caches only provide real advantages to complex packages, but do not provide many advantages to occasional autoconf users. Various reports are cited, and also the problem is mentioned that such kinds of failures tend to be quiet very often and are hard to debug. Correct. Even experienced people, who believe have understood config.caches and who actively take them into account during their works (Most users don't), often make mistakes related to them. Comments are appreciated. Please don't go this road. Config.caches should remain optional. Provided how HW has developed since the discussions from 10 years ago, you cited about, I am actually leaning towards proposing the converse of your proposal: Autoconf to consider to abandoning config.cache. Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: configure -C by default?
Ralf Wildenhues ralf.wildenh...@gmx.de writes: So one question would be what about making -C the default? We could have --force or --no-cache to turn it off. This behavior actually used to be the default. It was reverted around commit 5ae14bc8c048ed9a2dda6b67794ba (and also see commit 4abad4e9bfbcedd018302059844f8), 10 years ago. I must say, I'm not really sorry that it's turned off by default; I've been bitten way too many times by config.cache yielding out-of-date information. It's not at all uncommon that system configuration details change between runs of configure -- e.g. the common scenario of run configure, notice some package is missing, install it, re-run configure -- oops, configure _didn't notice_ because the information was cached... Configure is a lot faster on a modern system than it used to be back in the day, so presumably speed-related arguments for caching are _weaker_ now than when the decision was made to disable it by default... -Miles -- A zen-buddhist walked into a pizza shop and said, Make me one with everything. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: configure -C by default?
On 02/06/2011 03:11 PM, Ralf Wildenhues wrote: Apparently, a lot of users do not even know about configure -C aka. --config-cache which of course doesn't help Autoconf's reputation about producing configure scripts which are slow even for development. So one question would be what about making -C the default? We could have --force or --no-cache to turn it off. I prefer to keep it off by default, but wouldn't mind advertising that (when used correctly) it does provide great speedups within a single project. Personally, I use it all the time. It makes a HUGE difference for cygwin, but even on Linux, it is a noticeable speed improvement. And yes, stale caches are still very much a real issue - cross-package caches are too dangerous, and I have run into issues where stale caches bite me (for example, if gnulib enhances a configure test that marks a platform's function as non-compliant where it used to be compliant); I've gotten into the habit of nuking config.cache any time I update gnulib as a result. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: configure -C by default?
Den 2011-02-07 11:12 skrev Ralf Corsepius: On 02/07/2011 10:02 AM, Peter Rosin wrote: Den 2011-02-07 09:14 skrev Ralf Corsepius: Provided how HW has developed since the discussions from 10 years ago, you cited about, I am actually leaning towards proposing the converse of your proposal: Autoconf toconsider to abandoning config.cache. No, it still needs to be optional. I don't have anything against this. However, it's simply that the overwhelming majority of current packages hasn't been developed with config.caches in mind. And of those which really use it (complex packages such as GCC or GDB) occasionally to get things wrong. So, IMO, the advantage you believe to see on cygwin or mingw is of limited benefit. What do you mean by believe to see and of limited benefit? You are apparently not getting it, or you are downplaying my use case deliberately. The advantage I see for the packages I care about and regularly work on is very real: the experience moves from the pain in the ass category to bearable when I enable the cache. I'm not talking about one-time builds on Cygwin, I talking about doing development there. Cheers, Peter ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: configure -C by default?
On 02/07/2011 10:02 AM, Peter Rosin wrote: Den 2011-02-07 09:14 skrev Ralf Corsepius: Provided how HW has developed since the discussions from 10 years ago, you cited about, I am actually leaning towards proposing the converse of your proposal: Autoconf toconsider to abandoning config.cache. No, it still needs to be optional. I don't have anything against this. However, it's simply that the overwhelming majority of current packages hasn't been developed with config.caches in mind. And of those which really use it (complex packages such as GCC or GDB) occasionally to get things wrong. So, IMO, the advantage you believe to see on cygwin or mingw is of limited benefit. Not everybody have the luxury of running on the bare OS. E.g. Cygwin is not very fast at running configure and that matters a lot for me since I have a number of packages with checks for about the same things and they benefit *very* much from sharing the cache. :=) The only real world use-case I currently have for config.caches, is it being a offering a crude way to override configure settings when configure guesses things wrong (A real-world use case: Paths to tools when cross-building scripts) Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: configure -C by default?
On 02/07/2011 11:35 AM, Peter Breitenlohner wrote: On Mon, 7 Feb 2011, Ralf Corsepius wrote: The only real world use-case I currently have for config.caches, is it being a offering a crude way to override configure settings when configure guesses things wrong (A real-world use case: Paths to tools when cross-building scripts) My real world use-case is TeX live with a total of about 70 configure scripts and a very large number of common tests. Here -C gives a considerable speed-up with prcatically no problems. Quite possible, ... when things are designed to apply config.cache. In many cases this does not apply. Also consider that many modern autoconf/aclocal-m4-macros (those not being part of autoconf or automake) do not honor config.caches. Thus I'd certainly object to a removal of the cache file. Not much of a problem - Making configure -C default to me is not helpful. BTW, IIRC - and correct me if I am wrong, it used to be default and was removed around the time frame of the discussions Ralf W. cited. Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
configure -C by default?
Apparently, a lot of users do not even know about configure -C aka. --config-cache which of course doesn't help Autoconf's reputation about producing configure scripts which are slow even for development. So one question would be what about making -C the default? We could have --force or --no-cache to turn it off. This behavior actually used to be the default. It was reverted around commit 5ae14bc8c048ed9a2dda6b67794ba (and also see commit 4abad4e9bfbcedd018302059844f8), 10 years ago. Here's some discussion from back then, listed in the order in which I traced back things, that is, the last thread has the most info: http://sourceware.org/ml/autoconf-patches/2000-04/msg0.html http://sourceware.org/ml/autoconf-patches/2000-03/msg00274.html http://sourceware.org/ml/autoconf/2000-02/msg00271.html Back then, the consensus was to not make it the default because that was deemed too dangerous for users. Various reports are cited, and also the problem is mentioned that such kinds of failures tend to be quiet very often and are hard to debug. Comments are appreciated. Thanks, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Update GTK+ autotools configuration
Hello Javier, * Javier Jardón wrote on Sun, Feb 06, 2011 at 03:37:24AM CET: I'm trying to update the GTK+ autotools configuration [1] (comments welcomed ;)). The patches posted there look sane to me, at a glance. The semantic change to use pkg-config is one the maintainers need to decide over, of course. Also, I'd like to use the autoupdate program to verify that all the macros are updated but I get this error with current gtk master $ autoupdate /usr/bin/m4:/tmp/aukvr57a/input.m4:717: ERROR: end of file in string autoupdate: /usr/bin/m4 failed with exit status: 1 Any idea about how to solve this? Well, a first step would be to see that temp file; you can pass --debug to autoupdate to not remove them. But it's quite likely that we would need some way to reproduce this error, and that can be surprisingly hard at least sometimes: it might need the exact package tree you have, the old autotools it was bootstrapped with, and the new ones you're using now. OTOH, sometimes it's a lot simpler too. So, how about you show that input.m4 (gzip if large) and post exact tool versions that were, and are to be, used. Thanks, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Update GTK+ autotools configuration
Hello, I'm trying to update the GTK+ autotools configuration [1] (comments welcomed ;)). Also, I'd like to use the autoupdate program to verify that all the macros are updated but I get this error with current gtk master $ autoupdate /usr/bin/m4:/tmp/aukvr57a/input.m4:717: ERROR: end of file in string autoupdate: /usr/bin/m4 failed with exit status: 1 Any idea about how to solve this? Thanks, [1] https://bugzilla.gnome.org/show_bug.cgi?id=641640 -- Javier Jardón Cabezas ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
hierarchical config.site from distros? (was: configure -C by default?)
Even those Autoconf users who are aware of -C do not like the slowness of configure and the amount of tests that some projects use. Since we still lack some ideas for an efficient parallelization, we should maybe think about ways to speed up things for those users that build lots of packages, once, in a fairly similar environment. For example distro builders. Some random ideas gathered: Distributions could ship with a config.site base file for the base system which could contain information about the header files installed, the base types, and so on. Packages could then build upon that and add more information about now-installed header and library files. The default config.site file could look into a special directory and source some or all per-package site files in there, to gather all this information on the fly (and maybe even do some basic consistency checking?). One big question is whether the creation of such data could be done automatically. It is not likely to succeed if every package author or distro package maintainer has to invest much more work than invoking some script or package build hook, to do this extraction. Of course another question is whether such data can be generated safely at all. For example, header file existence is pretty safe, but whether the preprocessor actually accepts the header might even depend on whether some third-party header file is or is not installed. Related question would be to just assume that, if the dependency information in a distro package data base is correct, then these kind of issues cannot happen behind our backs. Autoconf could provide some kind of functionality to determine whether some cache variable is safe to keep. For simplicity, we probably need to limit using such site files to configure invocations without special CC, CFLAGS etc. settings. Comments and suggestions appreciated. Thanks, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: configure -C by default?
On Mon, 7 Feb 2011, Eric Blake wrote: On 02/06/2011 03:11 PM, Ralf Wildenhues wrote: Apparently, a lot of users do not even know about configure -C aka. --config-cache which of course doesn't help Autoconf's reputation about producing configure scripts which are slow even for development. So one question would be what about making -C the default? We could have --force or --no-cache to turn it off. I prefer to keep it off by default, but wouldn't mind advertising that (when used correctly) it does provide great speedups within a single project. I was at FOSDEM and i indeed didn't know that option before Ralf's talk. About using it correctly, is there some doc or tutorial about its usage ? Personally, I use it all the time. It makes a HUGE difference for cygwin, but even on Linux, it is a noticeable speed improvement. I use MSYS a lot, so if it can speed up configure time, it would help me a lot thank you Vincent Torri And yes, stale caches are still very much a real issue - cross-package caches are too dangerous, and I have run into issues where stale caches bite me (for example, if gnulib enhances a configure test that marks a platform's function as non-compliant where it used to be compliant); I've gotten into the habit of nuking config.cache any time I update gnulib as a result. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
