make-alpha
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: .ONESHELL enhancement?


From: David Boyce
Subject: Re: .ONESHELL enhancement?
Date: Sat, 3 Oct 2009 08:55:45 -0400

On Sat, Oct 3, 2009 at 6:12 AM, Ralf Wildenhues <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]