Re: [Xen-devel] [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.05.14 at 10:03, <mcgrof@xxxxxxxx> wrote:
> On Wed, May 21, 2014 at 12:32 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 20.05.14 at 19:54, <mcgrof@xxxxxxxx> wrote:
>>> On Tue, May 20, 2014 at 07:37:53AM -0600, Jan Beulich wrote:
>>>> >>> On 20.05.14 at 14:31, <mcgrof@xxxxxxxxxxxxxxxx> wrote:
>>>> > --- a/config/StdGNU.mk
>>>> > +++ b/config/StdGNU.mk
>>>> > @@ -1,3 +1,17 @@
>>>> > +# These are standard defaults which you can use to avoid having
>>>> > +# to run ./configure -- you can use this to compile the hypervisor
>>>> > +# and the mini os:
>>>> > +#
>>>> > +# make xen
>>>> > +# sudo make -C xen install
>>>> > +#
>>>> > +# make -C extras/mini-os
>>>> > +include $(XEN_ROOT)/config/defaults.mk
>>>> > +
>>>> > +# This comes from running configure and will override
>>>> > +# the defaults.
>>>> > +-include $(XEN_ROOT)/config/Toplevel.mk
>>>>
>>>> So what is the result of running one of the above make invocations
>>>> without having run ./configure, then running ./configure before
>>>> running the same make invocation (for an incremental update)
>>>> again?
>>>
>>> In my last v4 you pointed out two targets which you wished to
>>> ensure would not require running configure, both of those targets:
>>>
>>> make xen -j $(getconf _NPROCESSORS_ONLN)
>>> make -C extras/mini-os -j $(getconf _NPROCESSORS_ONLN)
>>>
>>> I have ensured this in this series and the above change indeed
>>> is what you were looking for.
>>
>> I understand that; what I was asking however was what the effect
>> of the named sequence of operations would be, i.e. whether that
>> then perhaps would unexpectedly change things between the
>> original and the incremental make runs. Obviously an incremental
>> make should change _only_ things where the contributing sources
>> changed, but nothing resulting merely from the intermediate
>> ./configure run.
> 
> Nothing I've introduced here should hamper the typical compile as what
> you described you want. Let me know if you find issues though. We're
> human.

Did you try it? I would expect the PREFIX change (from /usr to
/usr/local) alone would already alter things.

>>>> > --- /dev/null
>>>> > +++ b/config/defaults.mk
>>>> > @@ -0,0 +1,21 @@
>>>> > +# Build system defaults, in case you never ran ./configure, this is
>>>> > +# supported to be able to build the xen hypervisor and the mini os:
>>>> > +#
>>>> > +# make xen
>>>> > +# sudo make -C xen install
>>>> > +#
>>>> > +# make -C extras/mini-os
>>>> > +PREFIX ?= /usr
>>>>
>>>> Presumably this is meant to retain the previous setting from
>>>> StdGNU.mk, but being tree-wide this then is kind of in conflict with
>>>> the tools default of /usr/local
>>>
>>> It would seem that way but ./configure is required to compile tools
>>> and /usr/local/ is actually preserved as the default for tools if no
>>> prefix is specifified, just as before.
>>
>> I simply tried to point out an inconsistency that might be worth fixing
>> in the context of the re-work.
> 
> I hear ya, just tired to preserve the old behavior which is where I

s/tired/tried/ perhaps? Or else I don't understand why you simply
changed it to /usr/local.

Jan

> got those static non ./configure defaults. At this point from what
> I've observed anything as small as a needle could affect anything
> hugely in Xen so I would rather simplify the introduction of systemd
> without radical changes, and let things evolve slowly as atomic
> collateral evolutions over time where we could then bisect.
> 
>   Luis




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