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

Re: [Xen-devel] [PATCH] tools/stubdom: get rid of hardcoded pathes



On Thursday 28 May 2009 20:35:17 Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] tools/stubdom: get rid of 
hardcoded pathes"):
> > Attached patch makes xen-tools and stubdom-dm going independent
> >
> > >from hardcoded pathes. It is no possible to install into /usr/local or
> > > any
> >
> > other non-default directory and use it out-of-the box.
>
> I think this is a laudable goal but I'm not really convinced by the
> way you've done it.  Amongst my comments:
>
>
> Have you considered an arrangement which substitutes the correct paths
> into the relevant scripts at build time, rather than run time ?

Yes. The build system is doing this.

> Run-time searching can have problems as it means that you can
> sometimes find the wrong copy of something if there are multiple
> different installs.

I talked with the python people on irc.freenode.net what is the python
way to substitute certain patterns with pathes defined by the build system.
The answer: Python has no pre-processor like C. Therefore, have the build 
system to write the pathes into a file and use them. That is what I do.

Neither shell scripts have pre-precessors. So I have to do the same for
the hotplug scripts.


> > +buildmakevars2file = $(eval $(call buildmakevars2file-closure,$(1)))
> > +define buildmakevars2file-closure
> > +    .PHONY: genpath
> > +    genpath:
> > +   rm -f $(1);                                                    \
> > +   echo "SBINDIR=\"$(SBINDIR)\"" >> $(1);                         \
> > +   echo "BINDIR=\"$(BINDIR)\"" >> $(1);                           \
>
> This is really very ugly.  Surely it would be better to have the
> xen-setup[-stumbom] scripts fish things out of the build system,
> rather than plumbing everything through the environment like this.

To avoid maintaining three copies (tools/python/Makefile, stubdom/Makefile
and tools/hotplug/common/Makefile) each with its own tweaks and bugs, I moved 
the code from tools/python/Makfile into a GNU make macro.
If you know a better way, tell me.

> The only thing which _needs_ to be plumbed through from the
> commandline or en environment at install-time is DESTDIR or its
> equivalent.  We can insist on the rest being set in Config.mk or its
> ilk.

No, that's wrong. The way you suggest break the hotplug scripts
when you install into a non-default directory.

>
> The paths that stubdom looks at should not vary according to the host
> platform.  They should be fixed, as they need to be virtualised
> anyway.
>
> > --- a/tools/examples/xend-config.sxp        Thu May 28 11:07:19 2009 +0100
> > +++ b/tools/examples/xend-config.sxp        Thu May 28 18:15:43 2009 +0200
> > @@ -1,5 +1,7 @@
> >  # -*- sh -*-
> >
> > +from xen.util import auxbin
> > +
>
> *boggle*
>
> I stopped reading the patch at that point I'm afraid.

That's necessary to entangle xend from assuming the config files
are in /etc. W/o this, you can't really have a working installation
in a non-default directory.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Thomas M. McCoy, Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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