Re: Feature request: silently overriding existing rules
On 08/11/2012 07:36 AM, Tim Murphy wrote: 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. I dimly remember that there had been talks about a $(.TARGETS) special variable in the past, but for some reasons that had been problematic to implement correctly, and the idea was (at least temporarily) dropped. Perhaps the ability to detect if a target is defined and another to remove it would offer a complete api. But note that I'm just proposing to remove the *recipe* associated with a target, not the target itself (nor the list of dependencies for it). Not that I oppose such an enhancement, but is distinct from what I need for my use case (and might be more tricky to implement). Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Feature request: silently overriding existing rules
For the sake of understanding you properly, if you can detect, remove and add targets then 'replacing the recipe silently' is just these three operations in sequence, right? We can already add targets but not the other two. Cheers, Tim On Aug 11, 2012 10:53 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: On 08/11/2012 07:36 AM, Tim Murphy wrote: 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. I dimly remember that there had been talks about a $(.TARGETS) special variable in the past, but for some reasons that had been problematic to implement correctly, and the idea was (at least temporarily) dropped. Perhaps the ability to detect if a target is defined and another to remove it would offer a complete api. But note that I'm just proposing to remove the *recipe* associated with a target, not the target itself (nor the list of dependencies for it). Not that I oppose such an enhancement, but is distinct from what I need for my use case (and might be more tricky to implement). Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Feature request: silently overriding existing rules
On 08/11/2012 11:49 AM, Tim Murphy wrote: For the sake of understanding you properly, if you can detect, remove and add targets then 'replacing the recipe silently' is just these three operations in sequence, right? No. A target might be defined, but might have or not have an associated recipe. I was speaking only about changing such associated recipe, which GNU make is apparently able to do right today, albeit unconditionally printing a warning when it does so. It's because of this pre-existing ability that I suspect and hope it would be feasible to implement my originally proposed feature. We can already add targets but not the other two. Actually, we can already add targets *but not* remove nor detect them, and we can already add recipes *and* override them (we just cannot do so avoiding warnings), but OTOH we cannot detect (not that I know of). Regards, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Feature request: silently overriding existing rules
Even with GNU make as it stands, couldn't you emit your rules in the form of variables, override them at will, and eval() them at the end? E.g. define ruleA version 1 endef then later... define ruleA version 2 endef $(eval $(call ruleA,...)) -David Boyce On Fri, Aug 10, 2012 at 12:36 PM, Stefano Lattarini stefano.lattar...@gmail.com wrote: In some situations, it would be very useful to be able to override already-defined rules for a target without having GNU make complaining about the override. For example, when writing a library of makefiles recipes, organized as a set of makefile fragments to be included by a master (user-written) makefile, it is useful to be able to seamlessly override some of the recipes defined in those fragments from the master makefile. My Automake fork Automake-NG (whose generated Makefiles only target GNU make) could certainly take great advantage of such an ability in the future (near future in fact). I'm not sure what be the best way to implement my proposed feature. Some random ideas: - an all-encompassing option --no-warn-rule-override, that would suppress *all* warnings about overridden rules; - a new special target .OVERRIDABLE-RECIPES:, that would suppress the override warnings only for the rules specified as its prerequisites; - a new built-in to explicitly instruct make to clear the rule(s) so far associated to a target: $(clear-rules TARGET) This approach has the advantage of being very explicit, and to allow clearing of not only for normal rules, but also double-colon ones. - a new syntax to define special kind of rule for a given target -- a rule which can be silently overridden later; e.g., TARGET ?: commands that will be overridden ... TARGET : actual commands Note that I include this latter approach only for completeness; I rather dislike it, because it doesn't give enough power to the user -- the writer of the original makefile must decide statically and beforehand which rules to make overridable. Thoughts, objections, feedback? 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
Re: Feature request: silently overriding existing rules
Hi David, thanks for the feedback. On 08/10/2012 07:00 PM, David Boyce wrote: Even with GNU make as it stands, couldn't you emit your rules in the form of variables, override them at will, and eval() them at the end? E.g. define ruleA version 1 endef then later... define ruleA version 2 endef $(eval $(call ruleA,...)) Thanks for the tip. And now that I think about it, an even simpler and clearer idiom would be using GNU make ability of recipe canning http://www.gnu.org/software/make/manual/make.html#Canned-Recipes (which is a great, great feature IMO): define rule-foo do something @do something else, hiding the recipe do something else; \ that spans \ multiple lines endef define rule-bar @cmd1 @cmd2 endef ... # Then later ... foo bar: $(rule-$@) However, even my simplified idiom, if used throughout, would rapidly render the makefile library I was hinting to more cumbersome to write and to understand than I'd like; having a more native way to obtain the intended effect would be better. I guess in the end it will boil down to: is it be easier to consistently use the idiom above, or to enhance GNU make to implement my feature request? 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. Thanks, Stefano ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Feature request: silently overriding existing rules
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? 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. David ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Feature request: silently overriding existing rules
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
Re: Feature request: silently overriding existing rules
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
