Re: make: avoid breaking backwards compatability

[Jarmo Jaakkola <jarmo.jaakkola+netbsd-toolchain%roskakori.fi@localhost>]

On Wed, Sep 03, 2014 at 10:25:38PM +0000, Christos Zoulas wrote:
> Well, the problem is that now "suffix rules" cannot be controlled.
> I.e. if I have a foo.c and a foo.S in a directory I cannot say for
> arch x use foo.S and for arch y use foo.c.

ITYM they can't be controlled as finely.  You can still reorder
the suffixes to prefer either .c or .S.  If you need to decide on
an object-by-object basis, then you're out of luck.

But now that the support for $(<) is consistent, one could write:

    COMPILE_C = ...
    .c.o: ; $(COMPILE_C)
    ...
    foo.o: dir/foo.c ; $(COMPILE_C)

Or if one is willing to postpone the rule until the end of the file:

    OVERRIDE_C += foo.o
    foo.o: dir/foo.c
    ...
    .c.o $(OVERRIDE_C): ; ...

Sure, this isn't using the inference rules like it used to.  But this
is effectively the same and has the nice feature of using inference
without tricks where applicable and explicit rules where inference
does not work.

But yeah, you can't force it to choose some other rule or source
by putting it as an explicit dependency.

> For that reason we should add back compatibility code, but leave
> it off by default (so that we don't end up with Makefiles that use
> non-portable features again; see note below).

Please see the end of my response to David's email.

> NOTE: We depend on a large number of non-portable bsd-make features for
> our Makefiles anyway, and this is not easy to correct.

I'd also like a portable make process.  Too bad POSIX is so limited and
otherwise the implementations have too many incompatibilities.  It would
be nice to stress test the makefiles with a competing implementation
and stress test make with makefiles designed for another implementation.

-- 
Jarmo Jaakkola