[SM-Discuss] ./configure cache?
Seth Alan Woolley
seth at positivism.org
Wed Feb 9 13:19:39 EST 2005
On Wed, Feb 09, 2005 at 07:06:28PM +0100, Karsten Behrmann wrote:
> Hey guys!
> I dunno if this is the right time for this request, but I've had some
> requests (and done some thinking) on configure caching.
> Considering that for small spells configure takes twice as long as the
> actual build and e.g. on a nice quad-opteron is the only time delay
> you notice in a cast (1 minute configure, 3 seconds build), we maybe
> ought to think about adding configure caching.
> The only thing that needs to be done is to pass
> --cache-file=/usr/share/config.cache to ./configure.
> At least that's how it should be. Unfortunately, the cache can be
> invalidated by changing CFLAGS (so spells modifying CFLAGS should
> better not use config.cache at all...), which configure detects
> and bails out. A possible solution would be to delete the cache file
> if configure failed and to run it again. (maybe query)
> A more severe problem is that libs could change, configure cannot detect
> this. Therefore, I would suggest adding a "NO-LIBRARY" spell option
> that tells sorcery not to delete the configure cache after that cast.
> (because library changes can render the cache useless, it should be
> deleted by default)
> Of course, this would require modifications to spells and build_api
> to use this feature, though if nicely designed no spells should
> be broken if we phase it in.
> A downside would be that we could not detect if the configure failed
> because the environment (CFLAGS et al) changed or because it simply
> failed out. The return code at least seems to be 1 in both cases.
> So Far,
Maybe put config.cache in where the depends info is, then a cast -r can
clear it. Store it with a hash of the dependency info and CFLAGS, etc.,;
if it changes, it has to run configure again? If config.cache use
fails, just have it run configure without it, as you say.
Although config cache is mostly useful if you are doing debugging and
rebuilding the same version all the time with minor code tweaks.
It might be useful if version updates were frequent and small enough to
not affect configure a lot.
I'm just not really seeing all that much practical benefit, but whatever
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id EF10E21A = 36AD 8A92 8499 8439 E6A8 3724 D437 AF5D EF10 E21A
Security Team Leader Source Mage GNU/Linux http://www.sourcemage.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20050209/643226cc/attachment.bin
More information about the SM-Discuss