[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86emul: fix test harness and fuzzer build dependencies
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |