Re: .ONESHELL enhancement?

[David Boyce]

On Sun, Oct 4, 2009 at 4:50 AM, Ralf Wildenhues <address@hidden> wrote:
> 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.

I know very little about automake, so tell me where my logic is flawed:

One of the bedrock principles of autoconf/automake is that you
shouldn't make assumptions about what the target platform looks like.
In particular, you can't predict what make version will run the
generated Makefile, and thus reliance on nonstandard features is
discouraged. In fact the first line of the first hit when I google
Makefile.am says "automake processes Makefile.am to produce a
standards-compliant Makefile."

GNU make has dozens of extensions to "original" make: include, :=,
$(eval...), ifdef, $(CURDIR), etc. None of these are
standards-compliant and none should be - or as far as I've seen ever
are - employed in a Makefile.am. Why would people be be tempted
differently by this feature?

Bottom line, the arguments you make here could have been made against
any of the features mentioned above. Or against new features in
general: they can be misapplied, they won't solve everyone's problems,
they'll need to be documented, standards will have to catch up
eventually. This seems to me to be the ebb and flow of software
development.

David Boyce