bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU make release candidate 4.1.90 available for download


From: Brian Vandenberg
Subject: Re: GNU make release candidate 4.1.90 available for download
Date: Mon, 2 May 2016 15:45:16 -0600

On Sun, May 1, 2016 at 6:27 PM, Paul Smith <address@hidden> 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 <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]