[SM-Discuss] ./configure cache?
Seth Alan Woolley
seth at positivism.org
Wed Feb 9 14:20:03 EST 2005
On Wed, Feb 09, 2005 at 07:26:52PM +0100, Karsten Behrmann wrote:
> Seth Woolley wrote:
> > 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.
> Ah, I must've been a little unclear.
> The config.cache is not a spell-specific thing.
> Multiple spells can use the same cache, this way e.g compiling kde gets
> sped up quite a bit. If anything is missing in the cache file they add it,
> if it's already there they use it.
> However, config.cache use will NOT fail if system contents have changed,
> e.g a specific header added or removed. They will silently assume that
> header is still in the state it was when that cache entry was generated,
> not double-checking since that would be against the purpose of a cache.
> (the purpose of a cache is to be right, wasn't that what we said once ;-)
> Therefore, it does not only have to get cleared by a -r.
> Any spells that do anything with libraries can potentially disrupt the
> cache. I would suggest those would be all with "\.h$" matching anywhere
> in their install log. Unfortunately, I guess the cache would simply
> have to be deleted after a cast of one of them. I would not advise us
> to delete the cache based on the install log though. This should be
> set intelligently by the spell writers... (if they can manage)
Ah. I see. I think grepping the install log for files in
/lib,/usr/lib,(+paths in /etc/ld.so.conf) and *.h *.hxx would be more
intelligent than developers though, or is there a counterexample?
Perhaps we can allow developers to override the heuristics.
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/58136535/attachment.bin
More information about the SM-Discuss