>>> On 14.01.19 at 17:59, 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,
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
>>> On 14.01.19 at 16:09, wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH] x86emul: fix test harness and
> fuzzer build dependencies"):
>> On 21.12.18 at 15:16, wrote:
>> > Why is this particular inter-directory dependency unusual ? Do we
>&g
Jan Beulich writes ("Re: [Xen-devel] [PATCH] x86emul: fix test harness and
fuzzer build dependencies"):
> On 21.12.18 at 15:16, wrote:
> > Why is this particular inter-directory dependency unusual ? Do we
> > plan to introduce similar MAKELEVEL-based invocation of
>>> On 21.12.18 at 15:16, wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH] x86emul: fix test harness and
> fuzzer build dependencies"):
>> On 20.12.18 at 17:05, wrote:
>>> On 20.12.18 at 16:23, wrote:
>> >> Ie, it
Jan Beulich writes ("Re: [Xen-devel] [PATCH] x86emul: fix test harness and
fuzzer build dependencies"):
> On 20.12.18 at 17:05, wrote:
>> On 20.12.18 at 16:23, wrote:
> >> Ie, it is there to satisfy the requirement I mention above, that the
> >>
>>> On 20.12.18 at 17:05, wrote:
On 20.12.18 at 16:23, wrote:
>> Jan Beulich writes ("Re: [PATCH] x86emul: fix test harness and fuzzer build
>> dependencies"):
>>> On 20.12.18 at 15:46, wrote:
>>> > I think this introduces a `make -j' hazard ? The problem is that this
>>> > branch of the
>>> On 20.12.18 at 16:23, wrote:
> Jan Beulich writes ("Re: [PATCH] x86emul: fix test harness and fuzzer build
> dependencies"):
>> On 20.12.18 at 15:46, wrote:
>> > I think this introduces a `make -j' hazard ? The problem is that this
>> > branch of the Makefiles tree might enter
Jan Beulich writes ("Re: [PATCH] x86emul: fix test harness and fuzzer build
dependencies"):
> On 20.12.18 at 15:46, wrote:
> > I think this introduces a `make -j' hazard ? The problem is that this
> > branch of the Makefiles tree might enter tools/include while
> > another branch is also doing
>>> On 20.12.18 at 15:46, wrote:
> Jan Beulich writes ("[PATCH] x86emul: fix test harness and fuzzer build
> dependencies"):
>> --- a/tools/fuzz/x86_instruction_emulator/Makefile
>> +++ b/tools/fuzz/x86_instruction_emulator/Makefile
> ...
>>
Jan Beulich writes ("[PATCH] x86emul: fix test harness and fuzzer build
dependencies"):
> --- a/tools/fuzz/x86_instruction_emulator/Makefile
> +++ b/tools/fuzz/x86_instruction_emulator/Makefile
...
> +$(XEN_ROOT)/tools/include/xen/lib/x86/cpuid-autogen.h: FORCE
> + $(MAKE) -C
On 14/12/2018 08:49, Jan Beulich wrote:
> Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the
> userspace test harnesses") didn't account for the dependencies of
> cpuid-autogen.h to potentially change between incremental builds.
> Putting the make invocation to produce the header
Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the
userspace test harnesses") didn't account for the dependencies of
cpuid-autogen.h to potentially change between incremental builds.
Putting the make invocation to produce the header together with the
directory tree creation
13 matches
Mail list logo
