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
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
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 s
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 ove
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-cach
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 t
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
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 prop
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
Ralf Wildenhues 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 4abad4e9bfbcedd0183020
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 -
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 s
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
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 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 prop
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 u
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 ha
17 matches
Mail list logo