[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU make release candidate 3.99.90 available
From: |
Paul Smith |
Subject: |
Re: GNU make release candidate 3.99.90 available |
Date: |
Mon, 20 May 2013 09:24:40 -0400 |
On Fri, 2013-05-17 at 22:35 +0300, Eli Zaretskii wrote:
> When a dynamic extension is being remade, it is unloaded by calling
> unload_file. The latter looks up its argument in a linked list of
> loaded objects. Now, unload_file is called with file->name as its
> argument; is it 100% sure that this string will be identical to what
> was used in load_file? IOW, do we never change relative file names to
> absolute ones (or vice versa), mirror backslashes to forward slashes,
> or do any other transformations that produce a different string which
> points to the same file? If we can do such transformations, unloading
> will be unreliable.
Yes, I thought about this as I was making the change.
I believe it is true that the initial pathname will be identical.
However there are ways in which the path might change: for example
through use of VPATH. I'm not exactly sure how all this will play out
so it needs some testing.
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.