.ONESHELL enhancements

[Eric Blake]

Hello GNU make hackers,

In today's Austin Group meeting (the people working on POSIX), we
discussed an interesting proposal:

http://austingroupbugs.net/view.php?id=770

In summary, that proposal talks about standardizing the existing
RATIONALE text that suggests an extension that some make implementations
might want to provide:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html

"The default in some advanced versions of make is to group all the
command lines for a target and execute them using a single shell
invocation; the System V method is to pass each line individually to a
separate shell. The single-shell method has the advantages in
performance and the lack of a requirement for many continued lines.
However, converting to this newer method has caused portability problems
with many historical makefiles, so the behavior with the POSIX makefile
is specified to be the same as that of System V. It is suggested that
the special target .ONESHELL be used as an implementation extension to
achieve the single-shell grouping for a target or group of targets."

But as currently implemented in GNU make, there is no way to specify
.ONESHELL semantics for a group of targets - it is an all-or-none
decision, and what's worse, the decision made inside one included file
affects the behavior of the outer file doing the inclusion and all other
files.  In today's Austin Group call, the existing GNU implementation of
.ONESHELL was deemed unacceptable for standardization, if only because
the only way to convert over to using .ONESHELL as currently implemented
is to audit the entire suite of included files under a given Makefile
before being able to use the feature.  However, the idea itself still
has merit if we could come up with one or more ways to make it possible
to incrementally convert to this feature, making it easier for
"libraries" of includeable makefile snippets to be easily included in
various outer makefiles, regardless of what style the outer makefile
prefers to use.

Possible ideas mentioned on today's call:

* Add a .ENDONESHELL special target, so that .ONESHELL and .ENDONESHELL
can be used in pairs to bracket sections of the makefile that have
one-shell semantics.  But then you have to distinguish between .ONESHELL
used in isolation for a global effect, even for earlier lines, vs.
.ONESHELL/.ENDONESHELL used in pairs to leave earlier lines unchanged.
Furthermore, in the case of included files, you really want push/pop
semantics, where you push into .ONESHELL mode at the top of your file,
then pop back into the prior mode (whether that was oneshell or
multi-shell) at the end to leave the outer file semantics unchanged,
rather than unconditionally turning oneshell off.

* Enhance .ONESHELL to behave more like .IGNORE, where one could write:

.ONESHELL: foo
foo: bar
        echo 1 &&
        echo 2

where only the targets listed as prereqs of .ONESHELL are given oneshell
semantics, and all other targets remain multi-shell.  If .ONESHELL is
listed without prereqs, then it maintains its current meaning of a
global switch for all targets.

* Enhance .ONESHELL to be useful as a prerequisite, as in:

foo: bar .ONESHELL
        echo 1 &&
        echo 2

where the use of .ONESHELL as a target makes it obvious that foo will be
executed differently (and where you don't have to search possibly many
lines away to see if any .ONESHELL: list included foo in the list).
[For that matter, could .IGNORE also be enhanced to be used as a prereq,
in addition to its current semantics of being listed as the target whose
prereqs have changed behavior?]

* Add a .MULTISHELL or some other name to temporarily undo the effect of
global .ONESHELL.  Again, being able to select groups of targets rather
than being just an on-off switch would make this more appealing.

* Add a new special character, which if first in a recipe, means that
individual recipe uses oneshell semantics (probably less appealing than
the idea of an explicit prerequisite).


Do one or more of these ideas sound appealing for you to implement?  If
so, how hard would it be to turn it into existing practice in order that
we could revisit http://austingroupbugs.net/view.php?id=770 with an
actual wording proposal for the next version of POSIX?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature