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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.01.19 at 17:59, <ian.jackson@xxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH] x86emul: fix test harness and 
> fuzzer build dependencies"):
>> So how do we make progress here? For the two changes that
>> you dislike I don't formally need your ack, and I have Andrew's.
>> I would (have to) respect an active NAK of yours, of course.
> 
> As I say, I think you are trying to something that is not well
> supported by recursive make.  It follows that if any situations cause
> particular trouble, they should be documented rather than fixed; or
> maybe the general case should be documented too.  ("Only top-level
> make targets are fully supported; you may use deeper targets directly
> with make -C or by invoking make in a subdir, but at risk of
> erroneously not (re)building other parts of the tree".)
> 
> But I don't think this is important enough for a NAK.
> 
> I'm not sure what you mean by "make progress".  Do you mean "how can
> we dispose of this disagreement?"  I think our views are
> irreconcilable.

Not really, no. I'd be fine to accept an alternative solution,
provided one can still invoke at least "run" targets on their own
(and without the disclaimer you propose above). A possible
solution could be to introduce wrapper targets in the top level
Makefile, properly sequencing the two steps from there. I didn't
suggest that because I'm not eager to see a proliferation of
new top level targets.

> If you and other committers have listened to me and still want to
> commit this then so be it.
> 
>> For the one change that I need your (or Wei's) ack on, I didn't
>> see any strong objection so far, and this fixes an actual issue
>> with the overall tools build, i.e. _outside_ of the area you're
>> concerned about. The $(MAKE) invocation there is not overly
>> nice, but I thought I did convince you that - with the way
>> tools/include/ gets dealt with from the top level - this should
>> not be an issue. Plus I'm just moving it.
> 
> FAOD, the only thing I am objecting to is this kind of thing:
> 
>    +ifeq ($(MAKELEVEL),0)
>    +$(XEN_ROOT)/tools/include/xen/lib/x86/cpuid-autogen.h: FORCE
>    +       $(MAKE) -C $(XEN_ROOT)/tools/include build
>    +endif
> 
> This appears twice in your v2.  The rest I have no difficulty with.
> 
> I don't think it is sensible to turn this into an argument about whose
> bailiwick various hunks are in.  I am not going to cry foul if this
> gets committed, particularly if Andrew has reviewed this conversation
> and tells us that his ack stands.  I have said my piece.

Thanks, this clarifies matters enough from a process perspective.
Nevertheless I'd prefer if I could commit something which you do
not disagree with. Therefore, rather than asking Andrew whether
his ack stands despite the discussion, I'd prefer if we could come
to a workable solution both of us can live with.

Jan



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