Yes, thanks, that looks good; please install.
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
*
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
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
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
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
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
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
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
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
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
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:
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.
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
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
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
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
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,
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.
19 matches
Mail list logo
