Re: GNU make release candidate 3.99.90 available

[Paul Smith]

On Mon, 2013-05-20 at 19:06 +0300, Eli Zaretskii wrote:
> > I still don't want to add back the pointer to the struct.  Memory usage
> > by GNU make is becoming a sore spot, especially as larger and larger
> > build systems start to move to non-recursive make.  If necessary we'll
> > need to make the list a bit more sophisticated so we can add new
> > elements to it if/when we rename targets.
> 
> How about if we bite the bullet now, and simply add a fully qualified
> absolute file name of the dynamic object?

I'm not against it, but I'm not sure it's sufficient.  What we need is
to ensure that whatever name exists in the struct file can be looked up
in that list.

Make generally has a problem with multiple names for the same target.  I
had played with the idea of storing inode information to try to
determine if two different paths are the same file, but (a) that doesn't
work on non-POSIX systems so well, and (b) it doesn't help if some rule
recreates a file, giving it a new inode.

We have the "name" and "hname" values already, and the "hname" value is
intended to be a hashed lookup name which different "struct file"'s
referring to the same file will share, but this are not guaranteed to be
enough, I think.

Unfortunately finding the fully-qualified pathname of a file is VERY
expensive, so I don't think we can just do it as a matter of course.  To
get this working efficiently we'd need to keep some kind of cache of
fully-qualified directory paths, than we can try to figure out what
directory a given file belongs to.  Even this will be problematic
dealing with make rules which create/delete directories and/or symlinks,
and might invalidate the cache.  And handling symlinks that might change
directory paths can lead to problems trying to resolve paths like
"foo/../bar".

This entire area needs careful thought.  I believe there is at least one
Savannah bug related to this already.