jimmc@sci.UUCP (Jim McBeath) (04/15/88)
For various reasons, we do two slightly unusual things
with X here:
1) We load it onto a partition other than /usr.
2) After compiling it, we copy it to other machines
onto a partition which is different from where it
was built (and also not /usr).
X11R2 has solved the first problem quite nicely; I was
impressed with how easy it was to bring up in our non-
standard location. All I had to do was modify the DESTDIR
line in the *.macros file, and it all worked. My thanks
to the X developers for doing a great job on that.
My next problem is that, once built, it appears that I
can not simply tar off the bin directory (etc.), move it to
another partition, and have it run. I admit that I have
not yet actually tried this, but it appears that there are
a number of places in the code where paths are hard-coded
and can not be changed with command line switches or
environment variables.
I have a simple proposal which I think would solve this
second problem for me, and possibly make compiling X a little
simpler as well. The proposal is to have a single global
mechanism, readable at run time, which indicates where
the root directory is onto which X has been installed.
Here at SCS I use the environment variable XROOT to point
to the root directory, which contains /usr/bin, /usr/lib,
etc. In other words, XROOT is set to the same thing as
DESTDIR in the *.macros file. Rather than having the
DESTDIR part of the path compiled in, programs could look
for the environment variable XROOT and prepend it to the
default path. If XROOT is not set, then nothing is
prepended to those default paths, and they end up
referencing /usr/bin, /usr/lib, etc.
We are running both X10 and X11 in a heterogenous system
with NFS, so we have versions of X10 and X11 for Sun2, Sun3,
Sun4, Vax, and (eventually) Apollo all under one root
partition which is accessible from any of the machines.
I have made modifications to X10R4 and X11R1 to support
the XROOT mechanism, and it seems to work quite well.
(I will probably go ahead and make the same changes to X11R2.)
A user can select which version of X and which platform
simply by changing one environment variable; we can use
different paths to get to the software from different
machines; and we can move the software to another machine
or partition without having to recompile.
I would be interested in hearing what others think of this
proposal, and if there are any problems with it.rpd@CS.CMU.EDU (Richard Draves) (04/16/88)
Wow, it must be telepathy or something. Just last night I was thinking, "Boy wouldn't it be convenient if there was some kind of environment variable that dynamically changed DESTDIR in everything." This would work like the ANDREWDIR environment variable should work in the Andrew Toolkit. I build & run X11 in Vice, but not everyone here in CS yet trusts Vice (NIH, even though the ITC is 100 yards away), so some people want to copy the tree to their local file system and run it out of a different directory. When they do this now it looks like it works, but they aren't actually freed of their dependency on Vice because the server, for example, is still going to the Vice directory for fonts. Of course, they can manually overcome dependencies one by one, but it is a pain and not everything is configurable. One generalization that I think I would like is, instead of specifying a single directory, to specify a path (so call the variable XROOTPATH or something). This would be handy for us because we want to separate official MIT release stuff and random contributed/hacked code, fonts, etc. People who want to stick with official release software would just have the one directory in their path, and more adventurous types could add directories to the front of the path. Then the server would initialize its font path from the list, search for the rgb database down the path, etc, etc. Rich