[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |