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. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make