This is a different thing but I'd have had great use for a way to tell if a target had been defined previously. Had to use variables to do it which used a lot of memory and it was a total waste because make has the information already.
Perhaps the ability to detect if a target is defined and another to remove it would offer a complete api. Regards, Tim On Aug 11, 2012 1:32 AM, "Stefano Lattarini" <stefano.lattar...@gmail.com> wrote: > On 08/11/2012 01:27 AM, David Boyce wrote: > > On Fri, Aug 10, 2012 at 2:38 PM, Stefano Lattarini > > <stefano.lattar...@gmail.com> wrote: > >> I have no answer for that, lacking any knowledge about GNU make > >> internals; I guess the make developers here will be in a better > >> position to answer my question. > > > > Yes, and I hope you get your feature. But consider that auto-tools are > > traditionally targeted at the lowest common denominator. You've made > > an explicit exception for Automake-NG that it will require GNU make, > > which is reasonable. But do you really want to require a > > not-yet-even-released version? > > > No. But the nice thing is that we can support 3.81 and later if we > accept "graceful degradation": that is, make versions <= 3.82 will > print an "override" warnings unconditionally (annoying, but bearable), > while versions >= 3.83 will respect explicit user overrides, without > any spurious/redundant diagnostic. And the more the time passes, > the more the situation will improve (since more and more people will > be using 3.83 or later in the future). > > > That might not become generally > > available for a decade or so, depending how portable you want to be. > > It seems to me that targeting 3.81 or so would be better. IMHO. > > > That is currently our own target, yes (but I'm ready to just assume > make 3.82 or later if the first stable Automake-NG version will be > more than eight months from now). The argument about "graceful > degradation" given above shows that is not a problem in practice. > > Thanks, > Stefano > > _______________________________________________ > Bug-make mailing list > Bug-make@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-make >
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
