All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Egger <Christoph.Egger@amd.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] tools/stubdom: get rid of hardcoded pathes
Date: Tue, 2 Jun 2009 11:30:36 +0200	[thread overview]
Message-ID: <200906021130.37036.Christoph.Egger@amd.com> (raw)
In-Reply-To: <18974.55653.154784.824235@mariner.uk.xensource.com>

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

      parent reply	other threads:[~2009-06-02  9:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-28 16:42 [PATCH] tools/stubdom: get rid of hardcoded pathes Christoph Egger
2009-05-28 18:35 ` Ian Jackson
2009-05-28 19:49   ` Xen 3.4 / cpufreq=dom0-kernel / ondemand govenor doesn't step Carsten Schiers
2009-06-01  3:52     ` Liu, Jinsong
2009-06-01  7:47       ` Keir Fraser
2009-06-02  9:30   ` Christoph Egger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200906021130.37036.Christoph.Egger@amd.com \
    --to=christoph.egger@amd.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.