[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU make release candidate 3.99.90 available
From: |
Eli Zaretskii |
Subject: |
Re: GNU make release candidate 3.99.90 available |
Date: |
Mon, 20 May 2013 19:06:49 +0300 |
> From: Paul Smith <address@hidden>
> Cc: address@hidden
> 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.
How about if we bite the bullet now, and simply add a fully qualified
absolute file name of the dynamic object?