make-alpha
[Top][All Lists]
Advanced

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

Re: .ONESHELL enhancement?


From: Ralf Wildenhues
Subject: Re: .ONESHELL enhancement?
Date: Sun, 4 Oct 2009 10:50:11 +0200
User-agent: Mutt/1.5.20 (2009-08-09)

* David Boyce wrote on Sat, Oct 03, 2009 at 02:55:45PM CEST:
> - 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.

Well, part of the practical issue will be that users of Automake will
likely want to put .ONESHELL in their Makefile.am files so it applies to
their rules; but then it will apply to those generated by automake as
well.  So then Automake needs to either document that this is forbidden,
or adjust its rules.  The simplest way to do it of course causes more
overhead also for those not using .ONESHELL.

> It sounds like what you were dealing with in BSD
> was default behavior.

Not default.  It is enabled only if '-jN' is passed and '-B' is not also
passed.

> - The _intent_ of .ONESHELL is that when introduced into a working
> "traditional" makefile it should behave with the same semantics,

Yeah, well, part of my point is that this is impossible to achieve fully
transparently.  Even if you wrap each command in a (...), then you still
need to look for command line length limits; and anyway the optimization
can be detected by looking at the shell variable $$.

So whatever .ONESHELL does in the end, it needs to document the choice,
and that choice is part of the interface.  Which makes me wonder why
Posix reserved one but not tried to document the other.  Without
coordination with other systems' implementations, that can only cause
friction whenever this feature is standardized in a future Posix
version.  :-/

Cheers,
Ralf




reply via email to

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