[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] minimum Python version
Jan Beulich writes ("Re: [Xen-devel] minimum Python version"): > On 20.09.17 at 10:49, <jgross@xxxxxxxx> wrote: > > 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. > > If that's something that (a) can be reasonably expressed in > configure.ac and (b) the tools maintainers can live with, that's > certainly an option. I'd could live with that. Personally I think the whole purpose of configure is to allow automatic building of what's possible, leaving out anything else. So I think the default for this new option should be to suppress parts of the build whose dependencies are not satisfied, rather than to bomb out. (I wrote "nonessential parts" but I thinkthere are no essential parts. The hypervisor itself is already "nonessential" by this defininion - i386 builds skip it. And the tools are nonessential since you might be building on amd64 just for the hypervisor...) And, yes, configure can express that. It is an m4-generated shell script. My reservation is that this proposed new option would make every dependency for every feature more complicated. So to avoid that it would be necessary to invent new macros to generate the formulaic enable/disable code. I doubt anyone has the effort for that. Jan, I suggest you submit at the very least a patch to change the minimum to 2.6. Personally I would accept one to have it disable python instead of bombing out, if you would like to write it. That is the way we deal with many other nonessential components already. I think that if we want something more sophisticated, involving optionally bombing out on dependency trouble, it's up to people who want that to do the work. (As an aside, I don't think this is a distro/upstream division. With my Debian maintainer had on I actually prefer the automatic fallback. Our build-dependency system avoids accidental creation of broken packages in normal situations, and having graceful degradation makes it easier to do unusual things eg in derivatives, when cross-building, or whatever.) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |