Re: Idea: Enable .ONESHELL to be per-target

[David A. Wheeler]

> On Mon, Jun 10, 2019 at 4:56 AM David A. Wheeler <address@hidden> wrote:
> > Another idea: Enable .ONESHELL to be per-target.

On Mon, 10 Jun 2019 11:47:19 -0800, Britton Kerin <address@hidden> wrote:
> Strongly seconded, I would definitely use this.  I've been
> attracted to it many times but never dared try globally.
> Would make use of shell vars much less ugly and full of \
> lines etc.

Excellent!

> I do think some thought on the syntax might be in order still
> though.  With some of these it's not obvious which default
> sense would be more useful, e.g.
> 
>      # GLobal setting
>      .ONESHELL:
> 
>      tricky_target: .NOTONESHELL:
> 
> might be what is really wanted in many cases.

You can probably make a case for either one, but
.ONESHELL already exists, so let's just expand what's already there.
My theory is that in existing Makefiles
you would only enable .ONESHELL in specific cases,
so having ".ONESHELL" be the one you ask for in special cases
seems more sensible as the primary term.
Also, I think primary terms with a built-in negation are best
avoided. They force people work through double negatives
in many contexts.

If you want to disable a global special target
in a specific case, then I think there should be a general-purpose syntax
for this kind of thing.  Something like this:

~~~~
tricky_target: ! .ONESHELL
~~~~

(Instead of "!" it could be something else like ".NOT".)

I don't know if this negation case is worth supporting, but if it is,
having a reusable syntactic solution would be much better
than a weird special case.  It means there's less to remember
(the same approach works every time) and it's easy to generalize.


> I guess these would taint prereqs, like local vars do.

I don't think so; that wasn't my intention.

Currently .ONESHELL is a special target, not a (target-specific) variable,
and I intended to keep it that way.
It's my understanding that normally special targets
don't propagate when building their prerequisites.
E.g., a .PHONY target can depend on a non-.PHONY target.

Target-specific variables *do* propagate through their prerequisites
recursively, but that's different than a special target,
and I proposed this as a special target.
Did I misunderstand something?

Now the variables SHELL and .SHELLFLAGS *are* variables, and if you set
either one as a typical target-specific variable then that
*WOULD* propagate through the
prerequisites (like any other such variable).
The documentation for this should probably recommend that
if you set a target-specific value of SHELL then you should consider
defining it as a "private" value. I think that's probably a good idea
whether or not .ONESHELL had this extension.
But since GNU make already has private, override, etc.,
I think there's plenty of opportunity for control over these variables.

> > Note the ".SHELLFLAGS =", which is odd syntactically but should be allowed.
> > This also works nicely with "Idea: Allow certain special targets as 
> > dependencies":
> 
> Yes this would be nice.  And it's consistent with Make philosophy of
> trying to be
> very terse.  btw I assume these special prereqs would not be visible to $< etc

Whups, I totally forgot to spec that. Thanks for noting that!

Yes, I completely agree, these special prerequisites should *NOT* be
visible to $< etc., since they're directives syntactically expressed as
dependencies, not actual prerequisites.

Any other comments?

--- David A. Wheeler