On Sun, May 1, 2016 at 6:27 PM, Paul Smith <psm...@gnu.org> wrote: > On Sun, 2016-04-24 at 10:01 +0300, Eli Zaretskii wrote: > > Isn't it also true that the ABI for loaded modules has changed in this > > version? I see that the gmk_floc object now has a new member > > 'offset'. Should this be called out in NEWS? > > You're right. I reverted this change (or rather, I modified things so > that the gmk_floc type is the same as it was before and is only used by > the loadable object API, and that the rest of make uses a different type > which has the extra member). I feel that there's no need to have the > offset member visible through the loadable object API. >
On Mon, May 2, 2016 at 12:32 PM, Paul Smith <psm...@gnu.org> wrote: > On Mon, 2016-05-02 at 12:26 -0600, Brian Vandenberg wrote: > > When I made the patch for that, making it possible to get access to > > the current correct line number while inside a plugin is why I made > > those changes. Without offset in that struct the changes are useless > > to me. > > The only interface in gnumake.h which uses that structure is the > gmk_eval() function, so I'm not sure I know what you mean? > My apologies, I meant to reply to the list instead of you personally. Additionally my choice of words was unintentionally harsh; sorry about that. There's another issue I wrote that correlates with the one you applied: export "reading_file" in gnumake.h explicitly, or in lieu of that provide some other way to determine the current makefile/line number. Right now "reading_file" is a globally visible symbol so someone can make an extern declaration to get access to it, but getting into make internals like that when it's not explicitly part of the plugin API is dirty. In the documentation there's a way to get the current makefile, but it's not fool-proof: $(lastword ${MAKEFILE_LIST}). There's currently no way to get the current line number that I'm aware of. I have proof-of-concept plugin functions: $(current_makefile ) and $(current_line ) based on the hacky solution I just mentioned. It's especially useful for something like the following: SRC := $(wildcard $(dir $(current_makefile ))/*.cc) If this cannot be present for this release I can see the logic in delaying it because of the dll versioning issue, but consider this my request to give it some thought :) -brian
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make