| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] tools/stubdom: get rid of hardcoded pathes
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 ?
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.
> +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.
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.
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.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home