Re: Proposals for new features.

[Ramón García]

I think that the absolute preservation of backward compatibility is
quite reasonable. The interest of existing users who do not expect
suprises is legitimate.

The purpose of simplifying the syntax is to lower the barrier of entry
of new users. Adding tabs is not difficult, but it is unexpected, and
creates frustations to new users. This can decrease (and, as Microsoft
taught us, by a large factor) the actual number of users of a package.

Thus, the task is to make it compatible the interests of new users
with the interests of the existing users. This can be solved by being
careful. For instance, if make detects the new syntax without being
adviced to do so, it can give a warning.

Supporting these platforms like VMS is unfortunately imposible beyond
a best effort. Unless, of course, someone with access to that
platforms can help. This is what I did for this Summer grant: try to
leave existing code untouched; but I cannot honestly warrant that I
did not break anything.

Ramon


> However, other versions of make and indeed the POSIX rationale itself do
> provide for a special .ONESHELL: pseudo-target which, if defined, gives
> the behavior you mention: the entire recipe is passed to a single shell,
> preserving newlines and all.  I would love for this to be implemented.
Thanks for the information. I am not familiar with the POSIX standard, and this
sounds a very reasonable way of doing it.

> It seems like this could be handled with the existing eval capabilities,
> IF we enabled them to declare prerequisites in the second phase of
> processing (today there is a special flag that disallows this after the
> dependencies have been snapped).
>
> In order to do this the current snap_deps() needs to be enhanced so that
> it can be run at any time during make processing.  This idea leads to a
> LOT of complex situations that we'd need to consider and resolve (not to
> mention some non-trivial coding).

Ramon