tech-toolchain archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: make: avoid breaking backwards compatability
In article <20140903191158.GB9379%netbsd.org@localhost>,
David Holland <dholland-tech%netbsd.org@localhost> wrote:
>...basically you're saying that pattern rules no longer work for these
>cases.
Let's not call "suffix rules" (aka in the POSIX docs "inference rules")
"pattern rules" because "pattern rules" are something totally different.
Actually "pattern rules" were invented to generalize "suffix rules", and
address exactly this case.
>Note that I've been saying for years that .PATH and pattern rules for
>non-local files are bad and that makefiles shouldn't be written in
>this style; but that doesn't mean the feature should be arbitrarily
>lobotomized.
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 (I had to add that back
differently -- .INVISIBLE). Before you could say:
foo.o: foo.c
and that would force resolution of foo.o via foo.c even in the
presence of foo.S. Now it does not matter if you list any source.
Since we've fixed the build process for NetBSD, there is little
need for us to turn on backwards compatibility, but there is a large
number of 3rd party vendor Makefiles that expect the historical behavior.
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).
christos
NOTE: We depend on a large number of non-portable bsd-make features for
our Makefiles anyway, and this is not easy to correct.
Home |
Main Index |
Thread Index |
Old Index