Fwd: using .ONESHELL with just some targets

[Britton Kerin]

On Mon, Jan 10, 2022 at 8:45 AM Cook, Malcolm <MEC@stowers.org> wrote:
>
>
> >I'd like to migrate to .ONESHELL but I'm too scared to use it with
> >everything yet. Is there any way to apply it on a per-target basis?
>
> FWIW: Not to my knowledge.
>
> You *can* usefully use [Target\-specific Variable 
> Values](https://www.gnu.org/software/make/manual/make.html#Target_002dspecific)
>  to set .SHELL for selected targets.
>
> But the documentation does not indicate any similar provision for .ONESHELL.
>
> It would be nice if Gnu make supported it, perhaps with hijacking the syntax 
> for "order only" prerequisites; something like:
>
>         my/rule.txt: precond1 precond2 | .ONESHELL

I'm not sure about this particular syntax but if syntax is the issue
some solution would be nice to see.   .ONESHELL would be much more
useful if it could be adopted incrementally.  In theory I would think
you could just use multiple lines like e.g.:

     .ONESHELL: foo
     .ONESHELL: bar
     etc.

This seems intuitive in that the prereqs are unioned and then the
effect applied, much like how regular targets work when repeated
(prereqs are unioned and only one rule can have a recipe).  Which
leaves the global behavior of .ONESHELL: without prerequisites as a
bit of an oddity, buy oh well :)

I notice that .SILENT has what seems like it might be a syntax
limitation as well:

     $ cat Makefile
     .SILENT:

     .SILENT: target_a
     target_a:
             echo target_a_recipe

     target_b:
             echo target_b_recipe
     $ make target_b
     echo target_b_recipe
     target_b_recipe
     $

It looks like the .SILENT: with a recipe clobbers the .SILENT:
without, which is at best undocumented spooky action-at-a-distance wrt
target_b behavior.  Reversing the order of the two .SILENT:
declarations gives the same behavior.  I think what should happen is
the global .SILENT: (with no prerequisites) wins.  Whether other
.SILENT: with_targets in the same run should then result in an error
or warning is debatable.  I guess this could be a breaking change but
the present behavior seems clearly buggy.  Is there a strategy for
incrementally changing this sort of thing?

Britton