[45] in Zephyr Mailing List
"How i spent my time compiling zephyr"
daemon@ATHENA.MIT.EDU (Ken Manheimer)
Thu May 16 12:30:05 1991
Date: Thu, 16 May 91 11:48:31 EDT
From: klm@cme.nist.gov (Ken Manheimer)
To: zephyr@ATHENA.MIT.EDU
Well, i seem to have gotten a tidy zephyr installations done for my
site, and i've accumulated a bunch of notes about some finagling to
the installation setup (and a bit of source code, in zbrowser) along
the way. Here's a summary of my situation and finagles:
The subject - ZEPH0.2 release as obtained via anonymous ftp from
athena-dist.mit.edu about two or three weeks ago.
The target environment:
- many sun4 and sun3 systems running Sun OS (either 4.1 or 4.1.1).
(I have yet to build for our few decstations, but the installation
framework at least should transfer directly.)
- MIT X11r4 of fairly current patch level.
- We have gnu utilities, but i'm using SunOS cc, make, yacc, ... instead.
- the "depot" application installation framework (see below).
I built zephyr for sun4 and sun3 systems running SunOS 4.1/4.1.1. We
have X11r4, of fairly current patch level, installed here. I
initially took the task on for the sake of olc operation, but have
come to pursue it for its usefulness in its own right. However, i do
not have and am not building kerberos or hesiod.
My installation environment is somewhat peculiar. We use a highly
nfs-based arrangement (with the assistance of automount) where
platform-independent components of an application can be share between
the different platforms and platform-dependent components appear to be
installed in the same place regardless of platform. This allows us to
use the same installation configuration for our various Unix platforms
(currently sun3, sun4, and decstations). This means, however, that
the default locations that came with the distribution almost always
have to be changed for our site.
(For anyone interested in specifics about our installation framework,
the postscript code for a paper we did for the 1990 usenix LISA
conference is available for anonymous ftp from durer.cme.nist.gov
(129.6.32.4), in 'pub/depot/lisa-paper.ps.Z'.)
Most of the changes i had to make could be accomplished purely through
the very fine configuration scheme built in to zephyr. There was,
however, a number of problems that i encountered with implementing the
alternate arrangements, a few of which were caused by flaws in the
distributed Imakefiles. I'll details these problems in items 1 and 2
below, "Build Problems" and "Install Problems". Finally, there were a
few operational problems and oddities i encountered, which i'll cover
in 3 "Operation Oddities".
1 Build Problems:
- Problem with references to 'include/zephyr/krb.h' when trying to
build syslogd. I was able to get around this, but finally punted
since i believe the syslogd on my systems is enough like the 4.3
syslogd so that i don't need to build the zephyr one.
- Problems getting X11 libraries and includes from my nonstandard
installed locations. I had change some defines after the "END
LIKELY SITE-SPECIFIC CONFIGURATION" in 'config/config.Imakefile' in
order to accomodate these things. Mostly, i had to finagle the X
related macro vars so i could include the include and library
search paths in the compilation commands. This includes
definitions like:
X_CDEFS= -DX11 -I/depot/X11R4/include
and
X11_LIB=-L/depot/X11R4/arch/lib -lX11
- Real problems building zbrowser. References to a few ostensibly Xt
functions could not be resolved:
"Viewport.c", line 158: XtorientHorizontal undefined
"Viewport.c", line 158: XtorientVertical undefined
"Viewport.c", line 171: scrollbarWidgetClass undefined
I first looked for case problems, eg "XtOrient..." vs "Xtorient",
but i could never find any such functions in Xt. I did, however,
find similarly named functions in Xaw, and tried them instead. Had
to interject Viewport.c inclusion of Xaw headers,
#include <X11/Xaw/Scrollbar.h> /*klm*/
#include <X11/Xaw/ScrollbarP.h> /*klm*/
change function names (XawOrient{Horizontal,Vertical},
XawScrollbarSetThumb, etc), and then it compiled, and even ran.
Never found any zwgc windowgrams, however, and core dumped whenever
i hit the 'map' or 'unmap' buttons...
2 Install Problems:
- zwgc Imakefile had a number of install statement problems. The
ZCTLDESC definition was lacking a $(DESTDIR) prefix, so
ZCTLDESC=$(ETCATHDIR)/zephyr.desc
had to be changed to
ZCTLDESC=$(DESTDIR)$(ETCATHDIR)/zephyr.desc
I also wanted to have the zephyr.desc and zephyr.vars default
configuration files in platform-independent directories, which
meant having them located elsewhere than the executables which are
targeted in ETCATHDIR. I defined a seperate macro var,
DEFCONFSDIR, in config/config.Imakefile,
DEFCONFSDIR=/lib /*klm added for, eg, zephyr.{vars,subs,desc} */
and used it a new definition for ZCTLDESC:
ZCTLDESC=$(DESTDIR)$(DEFCONFSDIR)/zephyr.desc
The install statement for zephyr.desc did *not* refer to the
ZCTLDESC, so it would have to be changed two places to be
consistent. I changed the install statement to refer to this var
and another i created, for zephyr.vars, as follows:
ZCTLVARS=$(DESTDIR)$(DEFCONFSDIR)/zephyr.vars
Here's the rewrit install statement:
install::
$(RM) $(ZCTLDESC)
$(CP) zephyr.desc $(ZCTLDESC)
$(RM) $(ZCTLVARS)
$(CP) zephyr.vars $(ZCTLVARS)
- One more zwgc install peculiarity. As distributed, zwgc is
supposed to be installed in ETCATHDIR, yet it's clearly a client
to used by the general public. I changed the install target
location to be CLIENTDIR - is there a reason it should be in
ETCATHDIR that i'm missing?
- It would be nice, but probably difficult to arrange, for file
references in the distributed man pages to be parameterized so they
would default to the site-specific locations as designated in the
configuration scheme. I realize this would require additional
machinations, and only mention it in case doing something about
this is being considered, and encouragement would help it happen...
- Inconsistent with all other installation dirs, the 'include' target
dir suffix is hardcoded as '/usr/include'. It is generally
prefaced by $(DESTDIR) in the Imakefiles, but it would be nice to
be able to have, eg, $(DESTDIR)$(USRINCDIR), so i could globally
designate a target more suitable for my site.
3 Operation Oddities and requests:
- Should i be able to kill zhm with a regular 'SIGTERM'? It doesn't
die unless i send a 'SIGKILL', yet zephyrd and zwgc die on
'SIGTERM's.
- It would be *awful* nice to be able to dismiss zwgc windowgrams
using keyboard keys. Some of us avoid removing their hands from
the keyboard like we avoid the plague (except the plague is easier
to avoid around here). I can, and almost always do, move the
pointer between windows without touching the mouse, so dismissing
the windowgrams is one of the rare occasions where i have to do so.
(I have things set up so i almost never have to resize or move a
window, just about the only other window system actions that
require removing my hands from the keyboard.) Could a bit of code
be put in to enable keyboard bindings for dismissing, and otherwise
manipulating, the windowgrams?
- zwgc windowgrams do not seem to obey xrdb 'zwgc*geometry' or
'zwgc*Geometry' geometry specifications.
- Is there any way to get zephyr to look at typical Unix 'comsat'
notifications, so i can use zwgc instead of biff to get my mail
notifications?
- Is there any way to get a comprehensive list of the zctl variables,
is it dynamic, and could such a listing be built in to zctl. How
about having the zctl 'show' command take wildcards, for instance?
