Re: Fwd: Suggestion about derived files and commands

[Steven Knight]

On 27 Apr 2001, Dominique Dumont wrote:
> > I think what you want is the UseCache feature, which already exists.  It
> > stores derived files in a directory using the build signature as the
> > name.  That way, when you go back and remove the -DLAB_TEST flag, all of
> > the previously-built files are already in the cache and just copied in
> > to your build tree whenever the signature matches.
> >
> > Let me know if I misinterpreted what you're looking for.
>
> Uh, right. The cache provides this feature. This has one major drawback.
>
> As I wrote in my previous message, 2 commands may produce the same
> object file. So the same derived file will be stored twice in the
> cache directory.
>
> This may be a problem is you are dealing with a big software with
> several options. In this case,  the size of the cache may be huge if
> you want it to store one object file for each combination of options.

Okay, I see where you're going.  So this could be like the current
UseCache, but you want to map any build signatures that end up building
derived files with identical content to just one copy of the file on
disk.  Right?  This would be a good enhancement.

Files could be stored in the cache in file names that match their
content signature, not their build signature, and we'd have an index
file that would map the build signatures to the right underlying cached
file.  I'm sure that would save a lot of people a lot of space.

Are there any requirements you have in mind that would be left unmet by
an implementation like that?

> Furthermore, the "memoize like" feature has one other benefit:
> If cons recognize that the derived file to be produced is the same as
> the current derived file, there not need to follow the dependancies
> anymore for this file.

This is the same as Wayne Scott's content signature patch, which is
(with some generalization) on the verge of being checked in.

        --SK