Re: [Xen-devel] Kbuild and Kconfig

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.09.15 at 16:04, <cardoe@xxxxxxxxxx> wrote:
> On 9/3/15 5:31 AM, Jan Beulich wrote:
>>>>> On 02.09.15 at 19:50, <cardoe@xxxxxxxxxx> wrote:
>>> * target only the xen/ directory tree (i.e. not the toolstack, stubdoms
>>> or docs)
>> 
>> As just said in another reply, allowing for ./configure to pass down
>> options to the configure mechanism in xen/ would seem desirable (as
>> long as configuring in xen/ alone would still work).
> 
> My concern would be that the ./configure options would be pretty
> unwieldy. e.g.
> 
> ./configure --without-kexec --without-xenlinux --with-schedule=credit2
> 
> You would effectively have to write a script to contain what your
> "distro" (e.g. XenServer, Ubuntu with Xen, Amazon's build) wants.
> However the Linux kernel has a nice way to pass around a defconfig
> and/or .config files to ensure your build always behaves the same. Users
> also have an easy way to see what new options have been added since
> their .config was generated but autoconf does not have that.

And note that I didn't say this "ordinary" way shouldn't be possible;
in fact I meant it to be the default, with ./configure only allowed to
control things that aren't already set in xen/.config (or whatever
it's going to be named). The idea being that when you say
"--without-<xyz>" and it affects both parts of the tree, you won't
have to select the option another time in the hypervisor configure
process.

>>> * split top level config bits to not affect xen/ tree (currently only
>>> XSM_ENABLE / FLASK_ENABLE do)
>> 
>> As already said by someone else, this shouldn't be necessary. In fact
>> I would hope there's (other than debug-build-or-not) no top level
>> setting affecting both tools and hypervisor.
> 
> In the case of XSM_ENABLE and FLASK_ENABLE which are at the top level
> they do affect both the tools/ directory and the xen/ directory but in
> two totally different ways. For the tools side XSM is always enabled no
> matter the setting but setting either of those to 'n' results in the
> Flask policy not being built. For the xen/ directory it appears to
> disable XSM support. Hence why I argue that not having top level
> settings would be clearer from a usage standpoint.

I think where top level setting make sense (like enabling debug builds)
they should be made work. For existing things at the top level not
really belonging there I agree.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel