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

["Luis R. Rodriguez" <mcgrof@xxxxxxxx>]

On May 21, 2014 1:13 AM, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>
> >>> 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?

Tried only full install with cxenstored, oxenstored on both old init and systemd with and without systemd lib dev libs, with and without ocaml poo. I also tried to compile test what you asked, anything else I haven't tried so test results, reports and patches at this point are welcomed for all the other cases.

> I would expect the PREFIX change (from /usr to
> /usr/local) alone would already alter things.

That's only done upon configure, but maybe I'm missing something.

> >>>> > --- /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?

Tried. Which is what I tried.

> Or else I don't understand why you simply
> changed it to /usr/local.

That's the tools default upon default configure.

 Luis

> 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

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