Re: [Xen-devel] [PATCH] x86emul: fix test harness and fuzzer build dependencies

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Jan Beulich writes ("Re: [Xen-devel] [PATCH] x86emul: fix test harness and 
fuzzer build dependencies"):
> On 21.12.18 at 15:16, <ian.jackson@xxxxxxxxxx> wrote:
> > Why is this particular inter-directory dependency unusual ?  Do we
> > plan to introduce similar MAKELEVEL-based invocation of dependency
> > directory makefiles everyhere ?
> 
> If need be, anywhere where independent building of the sub-tree
> is specifically meant to work as a standalone operation. That
> invocation of "make -C ..../tools/include && ..." is in particular not
> meant to be necessary for the test harness'es "run" target. It is
> also not intended to be used for the fuzzer builds (as per
> tools/fuzz/README.afl), albeit there one might as well call it a doc
> omission.

This interface intent is inconsistent with the design principles for
recursive make, and can not, in general, be realised.

It can in some special cases, including I think this one, be realised
using MAKELEVEL, but only at the cost of significant extra complexity.
I see you've sent another patch based on MAKELEVEL.  I don't have a
strong enough objection to this change in this one place to block it.

However, I worry is that this is setting a precedent.
What is wrong is the idea that in general it is OK in xen.git to
start with a clean tree, or modify an existing build tree,, run
   make -C some/direct/ory
and expect everything to be (re)built as needed.  The result of
trying to implement that everywhere via MAKELEVEL would be awful.

Can you promise me not to send any more patches based on using
MAKELEVEL this way ?  If not, where does it end ?  Noting that even
your updated patch does not work for (eg):
   make -C tools/fuzz

Sorry,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel