[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v6 12/13] autoconf: xen: enable explicit preference option for xenstored preference

On Thu, Jul 03, 2014 at 10:20:40AM +0100, Ian Campbell wrote:
> On Wed, 2014-07-02 at 22:09 +0200, Luis R. Rodriguez wrote:
> > On Wed, Jul 02, 2014 at 02:54:31PM +0100, Ian Campbell wrote:
> > > On Thu, 2014-06-12 at 18:18 -0700, Luis R. Rodriguez wrote:
> > > > Since the xenstored preference
> > > > is explicit now and since we require configure substitutions for it we
> > > > make use of the AX_XEN_EXPAND_CONFIG() helpers as otherwise substitution
> > > > for SBINDIR is not propagated from the top level configuration.
> > > 
> > > I'm afraid I don't understand what is going on here. Why is SBINDIR not
> > > propagated?
> > 
> > Its saying that we need AX_XEN_EXPAND_CONFIG() in order to do substitutions
> > for variables that include SBINDIR in this case for the xenstore full path.
> Specifically you mean that the autoconf/m4 code now uses these variables
> in addition to them appearing in Paths.mk?


> Strictly speaking you don't
> need the associated AC_SUBST's but they are harmless.

Without the AC_SUBST() I do not believe substitiution is done by 
autoconf on Paths.mk.

> > > > Since we are now parsing an entry within Paths.mk.in on tools we let
> > > > the move the parsing of the file to be the tool's configure.
> > >
> > > I can't parse this.
> > 
> > I meant to clarify that since we now have to do a substitution on tools
> > we move the calls to AX_XEN_EXPAND_CONFIG() there. This patch should have
> > also removed the AX_XEN_EXPAND_CONFIG() from the top level configure.ac.
> I think moving it would break stubdoms under ./configure
> --disable-tools?
> I think I would suggest keeping AX_XEN_EXPAND_CONFIG and the generation
> of config/Paths.mk in the top level configure but call
> AX_XEN_EXPAND_CONFIG again in tools/configure.ac without the generation
> of config/Paths.mk (I think the AC_SUBST's are benign for this second
> call)

AX_XEN_EXPAND_CONFIG() is needed in both as we rely on some variable
substitutions like SBINDIR on the tools path as well.

> > After testing this though and removing AX_XEN_EXPAND_CONFIG() from 
> > configure.ac
> > I do see though that substitution doesn't work, it only works if we leave
> > AX_XEN_EXPAND_CONFIG() on both places. 
> I should have read this next para before commenting above!

OK I take it this means I can keep it on both?

> > This is the issue I mentioned that
> > I ran into and you had proposed we could try to figure out a fix if
> > this was happening. Well it is. Any ideas ? Or are you OK to live with
> > calling AX_XEN_EXPAND_CONFIG() twice, once on configure.ac and another
> > on tools/configure.ac ?
> Yes, so long as the generation of config/Paths.mk remains in the
> toplevel configure only.

OK so use AX_XEN_EXPAND_CONFIG() on both top level configure.ac and
tools/configure.ac but only have config/Paths.mk be a AC_CONFIG_FILES()
for the top level configure.ac ?

I think that's how the v6 patch was then.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.