keith@sequoia.execu.com (Keith Pyle) (02/21/91)
I've just found myself responsible for installing X11R4 on a group of DEC machines running Ultrix 4.1. If the following is a frequently asked question, please (gently) point me to the right source as I haven't spotted anything about this in the past few days of news. Is it possible/practical to install X11R4 somewhere other than in the default directories of /usr/bin/X11 and /usr/lib/X11? I would prefer that both of these be in the /usr/local tree since this is readily available across our DEC workstations. The default means more manipulations of mounts and links since I don't have the disk space to put it on each and every one of them (nor would I!). Are there any negative aspects for X11 to using an alternate installation destination such as I mention? I can see from Imake.tmpl that there are values such as DestDir, UsrLibDir, and IncRoot, but there isn't any clear description of them or whether this is a reasonable way to affect the change I would like. If this is The Way, is it sufficient to put the appropriate defines in my .cf file? Thanks. -- ----------------------------------------------------------------------------- Keith Pyle UUCP: ...!cs.utexas.edu!execu!keith Execucom Systems Corp., Austin, Texas Internet: keith@execu.com "It's 10 o'clock. Do you know where Disclaimer: Everything I say is your child processes are?" true unless I use the word 'the'. -----------------------------------------------------------------------------
merlyn@iwarp.intel.com (Randal L. Schwartz) (02/21/91)
In article <32602@sequoia.execu.com>, keith@sequoia (Keith Pyle) writes: | Is it possible/practical to install X11R4 somewhere other than in | the default directories of /usr/bin/X11 and /usr/lib/X11? I would | prefer that both of these be in the /usr/local tree since this is | readily available across our DEC workstations. The default means | more manipulations of mounts and links since I don't have the disk | space to put it on each and every one of them (nor would I!). Are | there any negative aspects for X11 to using an alternate installation | destination such as I mention? | | I can see from Imake.tmpl that there are values such as DestDir, | UsrLibDir, and IncRoot, but there isn't any clear description of | them or whether this is a reasonable way to affect the change I | would like. If this is The Way, is it sufficient to put the | appropriate defines in my .cf file? Well, what I did here was use the default settings on all the paths, and then said: make World make DESTDIR=/local/X11R4 install install.man /local/X11R4 is an architecture-specific symlink to a common NFS-mounted area (similar to your /usr/local shared mounts, apparently). I then went in on each machine and executed a script that did the equivalent of: for i in bin lib include man/mann man/man3 do ln -s /local/X11R4/usr/$i/* /usr/$i done Actually, my script pays attention to symlinks that need to be removed as well, and looks at dotfiles, but you get the idea, I hope. Works like a charm. The only gripe is having to rerun that script on each box every time I add a new tool (because the addition of a manpage requires a file symlink, not a directory symlink). I s'pose I could have /usr/man/manx and require people to put that in their MANPATH, but this is more user-friendly. (The script is in Perl, of course, and also handles linking into the client /export/root area for diskless clients.) Just another new X hacker (and Perl hacker), -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Intel: putting the 'backward' in 'backward compatible'..."====/
sean@dsl.pitt.edu (Sean McLinden) (02/24/91)
In article <32602@sequoia.execu.com> keith@sequoia.execu.com (Keith Pyle) writes: >Is it possible/practical to install X11R4 somewhere other than in >the default directories of /usr/bin/X11 and /usr/lib/X11? Yes/no. It is possible, it may even be practical in some situations, but my experience doing this on a few different networks is that you don't want to unless you *absolutely* have to. The problem stems from the fact that X11 inherited the 4.2bsd-style of file system organization which, in turn, suffered from a limitation in user definable library paths for the ld(1) link editor. That limitation was that ld would search only /lib and /usr/lib (and later, /usr/local/lib) for ranlib'd archives. Perhaps in keeping with this tradition, the implementors of X11 chose to root the X11 libraries in /usr/lib (although resources and fonts and things are in /usr/lib/X11). In the best of all possible worlds, X11 *should* have been installed in a single directory rooted in X (or X11) as in: % ls /usr/X11 adm bin etc lib src tmp or some such thing. Packages such as Serpent, KHOROS, and the Brown Workstation Environment, do follow this convention. X, does not. >Are there any negative aspects for X11 to using an alternate >installation destination such as I mention? If you define your X config files correctly, X will build and run OK. The headache exists because in some (actually many) cases, contributed and ftp'able software rely on hardcoding paths to the /usr/lib stuff and, in particular, /usr/lib/X11. Many applications don't use the /usr/lib/X11/config files for certain parts of the build causing you problems with resources and application defaults and even fonts. This is the simplest case. One in which there is no X distribution to begin with. A more complicated case exists for something like the DEC/Ultrix/DECWindows environment where, until your build is complete and fully tested, you need to maintain separate and distinct paths. The DEC Ultrix install utility forces you to install the basic DECWindows distribution so you cannot, easily, start out with a vanilla Ultrix and build an X on it. You can, of course, build symbolic links to everything. That is what we have had to do. In fact, what we ended up doing was to build a separate X11R4 hierarchy, move to it, and then build another with the defaults once the DECWindows stuff was completely purged. I am hoping that by the time X11R5 comes around there will be a move toward 4.4ish style file systems and X11 will exist, totally, in its own hierarchy. Then it will be simpy a matter of a single link or a single mount point to switch distributions, versions, whatever. Sean McLinden Decision Systems Laboratory University of Pittsburgh Medical Center
karl@rice-chex.ai.mit.edu (Karl Berry) (02/25/91)
It is possible to install into directories beneath /usr/local (or wherever), and avoid symbolic links or other hacks altogether. I defined UsrLibDir, IncRoot, and BinDir in mit/config/site.def. The ERRATA sheet also specifies several changes to make (items #1 and 2). The place I use symbolic links is to share the include files, app-defaults files, man pages, etc., between architectures. End of technical information, beginning of opinion: Personally, I think the X documentation makes too big a fuss about leaving the default paths as they are and setting symbolic links, even forgetting about those systems which don't have symlinks. Granted, X is a large and important software package for a system to have. But it is not the only large and important software package. It would be a system administrator's nightmare if TeX, Emacs, Ingres, RCS, etc., etc., all insisted on their own favorite paths. (At least it's possible to install X in other places; I'm told that the Interleaf publishing system *requires* a directory /interleaf to work. Now that's chutzpah.) karl@cs.umb.edu
gam@lanl.gov (Gim Mark) (02/27/91)
In article <1991Feb23.164951.4655@dsl.pitt.edu>, sean@dsl.pitt.edu (Sean McLinden) writes: > In article <32602@sequoia.execu.com> keith@sequoia.execu.com (Keith Pyle) writes: > >Is it possible/practical to install X11R4 somewhere other than in > >the default directories of /usr/bin/X11 and /usr/lib/X11? > > Yes/no. > > It is possible, it may even be practical in some situations, but > my experience doing this on a few different networks is that you > don't want to unless you *absolutely* have to. The problem stems > from the fact that X11 inherited the 4.2bsd-style of file system > organization which, in turn, suffered from a limitation in user > definable library paths for the ld(1) link editor. I've come across another problem, which arises when you're developing X applications and you've installed the X distribution in a non-standard place. Many of the include files in the MIT distribution themselves contain directives of the form #include <X11/Xlib.h> That is, these directives require that the X11 headers be under certain system-defined directories. If you install the release say in /usr/tmp, cpp will fail on these directives when you try to compile your own X application. The only solution I've come up with is to alter the directives to the form #include "Xlib.h" Graham Mark Los Alamos National Laboratory
bin@primate.wisc.edu (Brain in Neutral) (02/28/91)
From article <16001@lanl.gov>, by gam@lanl.gov (Gim Mark): | I've come across another problem, which arises when you're | developing X applications and you've installed the X distribution | in a non-standard place. | | Many of the include files in the MIT distribution themselves | contain directives of the form | | #include <X11/Xlib.h> | | That is, these directives require that the X11 headers be under | certain system-defined directories. If you install the release say | in /usr/tmp, cpp will fail on these directives when you try to compile | your own X application. | | The only solution I've come up with is to alter the directives to the | form | | #include "Xlib.h" Wouldn't it work to put INCLUDES = -I/tmp/cpp/whatever in your Imakefile? There are all sorts of include directory-setting symbols in the configuration files, but INCLUDES is the one intended for you to be able to use yourself. -- Paul DuBois dubois@primate.wisc.edu
milton@en.ecn.purdue.edu (Milton D Miller) (02/28/91)
In article <3977@uakari.primate.wisc.edu> bin@primate.wisc.edu writes: >From article <16001@lanl.gov>, by gam@lanl.gov (Gim Mark): [Re: Builds in alternate places. MIT files have:] >| >| #include <X11/Xlib.h> [meaining in the system defined directories, his solution was:] >| #include "Xlib.h" > >Wouldn't it work to put > >INCLUDES = -I/tmp/cpp/whatever > >in your Imakefile? [...] >but INCLUDES is the one intended >for you to be able to use yourself. INCLUDES Is for the APPLICATION SPECIFIC includes. Why would you want to edit every Imakefile, when it is taken care of by TOP_INCLUDES ? I don't think this was one of the changes I made while installing R4 with DESTDIR=/tmp/four (don't ask). I didn't have to make many (any?) changes for the programs I wanted, but I didn't remake programs that were already in R3. I did make some net stuff, though. (TOP_INCLUDES and INCLUDES are combined with STD_INCLUDES and some others). (Getting the config figured out is another matter). milton #ifndef IncRoot #define IncRoot $(DESTDIR)/usr/include #endif #ifdef UseInstalled TOP_INCLUDES = -I$(INCROOT) /* def: for alternative /usr/include */ #else TOP_INCLUDES = -I$(TOP) /* def: for builds within tree */ #endif
bin@primate.wisc.edu (Brain in Neutral) (03/01/91)
From article <1991Feb28.060558.21908@en.ecn.purdue.edu>, by milton@en.ecn.purdue.edu (Milton D Miller): |>Wouldn't it work to put |> |>INCLUDES = -I/tmp/cpp/whatever |> |>in your Imakefile? | [...] |>but INCLUDES is the one intended |>for you to be able to use yourself. | | INCLUDES Is for the APPLICATION SPECIFIC includes. Why would you want | to edit every Imakefile, when it is taken care of by TOP_INCLUDES ? I | don't think this was one of the changes I made while installing R4 with | DESTDIR=/tmp/four (don't ask). I didn't have to make many (any?) | changes for the programs I wanted, but I didn't remake programs that | were already in R3. I did make some net stuff, though. (TOP_INCLUDES | and INCLUDES are combined with STD_INCLUDES and some others). (Getting | the config figured out is another matter). Well, that's OK, but it sounds to me like you're talking about building part of the X distribution, whereas the poster to which I was replying was, despite the article title, building his own applications, and wanting to *access* includes installed in a non-standard place (not install them there). So he could just as well use the application specific include symbol. Your solution would work, too, I think. -- Paul DuBois dubois@primate.wisc.edu
warsaw@nlm.nih.gov (Barry A. Warsaw) (03/06/91)
Folks who are interested in this topic, and a related one -- sharing a single source tree for all platform installations of X11 (and other large software packages), may want to check out a paper published in Usenix LISA IV proceedings last October entitled "The *Depot*: A Framework for Sharing Software Installation Across Organizational and UNIX Platform Boundaries". Here's the abstract: "The *depot* is a coherent framework for distributing and administering non-OS distribution UNIX applications across extensibly numerous and diverse computer platforms. It is designed to promote reliable sharing of the expertise and disk resources necessary to maintain elaborate software packages. It facilitates software installation, release, and maintenance across multiple platforms and diverse host configurations. We have implemented the *depot* using conventional UNIX subsystems and resources combined with policies for coordinating them. This paper presents the specific aims, structure, and rationale of the *depot* framework in sufficient detail to facilitate its implementation elsewhere." This was authored by myself and my former co-workers at the National Institute of Standards and Technology (Kenneth Manheimer was principle author). While not specifically addressing the installation of X in alternative locations, it was necessary to accomplish this in order to "depotize" the X11 distribution, so many details were worked out by the folks involved in the depot's development. The paper can be ftp'd from durer.cme.nist.gov [129.6.32.4] under pub/depot. Both the paper and the presentation slides (in postscript form) are available. If you don't have ftp access, send the message "help" to the archive server address: library@cme.nist.gov. For more information about the depot, or specifically about depotizing X11, there is a mailing list which you can contact: Administrivia to: depot-request@cme.nist.gov Articles to: depot@cme.nist.gov -Barry NAME: Barry A. Warsaw INET: warsaw@nlm.nih.gov TELE: (301) 496-1936 UUCP: uunet!nlm.nih.gov!warsaw