Re: [Xen-devel] [PATCH 01/13] libx86: Introduce libx86/cpuid.h

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.07.18 at 03:35, <cardoe@xxxxxxxxxx> wrote:
> On Wed, Jul 04, 2018 at 07:57:30AM -0600, Jan Beulich wrote:
>> >>> On 04.07.18 at 14:03, <andrew.cooper3@xxxxxxxxxx> wrote:
>> > On 04/07/18 09:21, Jan Beulich wrote:
>> >>>>> On 03.07.18 at 22:55, <andrew.cooper3@xxxxxxxxxx> wrote:
>> >>> --- a/tools/include/Makefile
>> >>> +++ b/tools/include/Makefile
>> >>> @@ -21,6 +21,9 @@ xen/.dir:
>> >>>          ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h 
>> >>> elfstructs.h) 
> xen/libelf/
>> >>>          ln -s ../xen-foreign xen/foreign
>> >>>          ln -sf $(XEN_ROOT)/xen/include/acpi acpi
>> >>> +ifeq ($(CONFIG_X86),y)
>> >>> +        ln -sf $(XEN_ROOT)/xen/include/xen/libx86 xen/libx86
>> >>> +endif
>> >> Why not set the include path suitably?
>> > 
>> > Because this is how everything else is currently done.  If we want to
>> > change how tools get their hypervisor header files, that should be
>> > independent work.
>> 
>> How this gets done here has no direct implications on pre-existing
>> mechanisms.
> 
> While not wrong refactoring the build system appears to be orthogonal to
> the entire series. This had been proposed before when I tried to
> separate the xen and tools build systems apart before and I do not
> recall why it wasn't done.

I don't understand: I've not said the current model needs refactoring
_in this series_ (it's likely worthwhile as an independent task). Leave as
is what is there, but don't tie yourself to doing new things the same way.

Jan



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