On 20/09/17 09:55, Jan Beulich wrote:
>>>> On 20.09.17 at 09:20, <jgr...@suse.com> wrote:
>> For your case: what about adding a configure option to disable building
>> the python bindings (and any dependencies like e.g. pygrub) instead of
>> doing so in case of a version mismatch? This would avoid any surprises
>> in case someone didn't notice that the bindings have been disabled.
> That's certainly an option, but I'm generally not very happy with
> having to add such options. My script invoking configure becomes
> more and more unreadable because of such, since this way the
> requirement to do the version check gets moved from the build
> system (i.e. configure, whose job this is imo) to that script. And
> as you can probably understand I don't want to unilaterally
> disable the building of that code, to be able to build test possible
> changes I may end up making to e.g. libxc.
> IOW if such a configure option was added, I'd still think it should
> default to disabled if the Python in use is not new enough.
I can understand your concerns.
OTOH it is quite nasty to find out that due to a missing or too old
package on the system some parts of Xen haven't been built without
having them disabled via configure (I had this experience more than
once, e.g. with a Mini-OS patch breaking vtpm stubdom which I didn't
notice as it wasn't being built on my side).
What about the following idea: maybe we could add an option to configure
to make it fail instead of disabling components in case some
requirements for that component are not met? The default could be to
just disable the components and with the option specified all components
not disabled explicitly must be buildable or configure will fail.
Xen-devel mailing list