On Fri, Jul 16, 2021 at 02:15:28PM +0100, Andrew Cooper wrote: > On 15/07/2021 07:25, Jan Beulich wrote: > > On 14.07.2021 18:17, Anthony PERARD wrote: > >> --- a/xen/common/Kconfig > >> +++ b/xen/common/Kconfig > >> @@ -25,6 +25,9 @@ config GRANT_TABLE > >> config HAS_ALTERNATIVE > >> bool > >> > >> +config HAS_CHECKPOLICY > >> + def_bool $(success,$(CHECKPOLICY) -h 2>&1 | grep -q xen) > >> + > > This is no different from other aspects of "Kconfig vs tool chain > > capabilities" sent out last August to start a discussion about > > whether we really want such. Besides Jürgen no-one cared to reply > > iirc, which to me means no-one really cares one way or the other. > > You know full well that upgrading Kconfig was specifically to be able to > use this functionality, and you know full well that I firmly support
To be honest, I've upgraded Kconfig mostly because I needed to start somewhere with upgrading our build system to look more like Kbuild. I may have adding `CC --version` and some other CONFIG_* running shells, but I don't think anymore that is a necessary things to do, it just look cleaner. > using this mechanism, because we've had both of these arguments several > times before. I'd like to read about your (or someone else's) arguments in favor of doing more in Kconfig only, do you have links (or maybe subject, keyword) to look at? I think I understand Jan's arguments. Cheers, -- Anthony PERARD
