Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

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

-- 
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id EF10E21A = 36AD 8A92 8499 8439 E6A8  3724 D437 AF5D EF10 E21A
http://smgl.positivism.org:11371/pks/lookup?op=get&search=0xEF10E21A
Security Team Leader Source Mage GNU/Linux http://www.sourcemage.org

Attachment: pgppgRRjh40Dn.pgp
Description: PGP signature