In short:
I think, no cache loading from manual explicite configure run
(but for sub-packages and make-triggered), keeping it as it is.
By this, if in doubt, by re-running all build tools, chances are
best to get a correct result. Performance tuning for the price of
correctness isn't always a
Hello Vincent,
* Vincent Torri wrote on Mon, Feb 07, 2011 at 07:37:57PM CET:
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
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
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.
.
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
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
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.
16 matches
Mail list logo
