Re: .ONESHELL enhancement?
David Boyce <[email protected]>
| Newsgroups | gmane.comp.gnu.make.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Oct 3, 2009 at 6:12 AM, Ralf Wildenhues <[email protected]> wrote: > David Boyce writes: > It may > be helpful to state a few pitfalls I've encountered, so this is FYI... > [snip] These are all good points, but I have the impression you may have responded before reading through the rest of this rather long thread? Anyway, I don't see the issues you raise as being applicable to the GNU make situation for the following reasons: - This feature will (must) have absolutely no effect on the default behavior of GNU make. Since automake aims to generate lowest-common-denominator makefiles there's no chance it will ever emit a Makefile containing a .ONESHELL target, so I don't see any crossover problems. It sounds like what you were dealing with in BSD was default behavior. - The _intent_ of .ONESHELL is that when introduced into a working "traditional" makefile it should behave with the same semantics, just fewer shell invocations on average (it also makes it easier for nontraditional makefiles, which would not be compatible with other makes or older GNU makes, to be written but that's a different topic). You're right of course that there are subtleties which can affect corner cases, which according to them is why POSIX didn't mandate .ONESHELL as the default in the first place, but in any case you don't get it unless you ask for it and if it breaks anything you can take it back out. - Performance is not the main point, though of course faster is always better. For my purposes the main point is that each recipe has one unique parent process. Other people are excited about writing recipes in Perl or Java or whatever. - Yes, this could be an additional strain on line length limitations. Again, if it doesn't work for someone, they don't need to use it. Thanks, DSB