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
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
