[Top][All Lists]

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

Re: Feature request: silently overriding existing rules

From: David Boyce
Subject: Re: Feature request: silently overriding existing rules
Date: Fri, 10 Aug 2012 13:00:04 -0400

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?

define ruleA
version 1

then later...

define ruleA
version 2

$(eval $(call ruleA,...))

-David Boyce

On Fri, Aug 10, 2012 at 12:36 PM, Stefano Lattarini
<address@hidden> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-make

reply via email to

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