Path: utzoo!mnetor!tmsoft!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!uwvax!gjetost!solomon
From: solomon@gjetost.cs.wisc.edu (Marvin Solomon)
Newsgroups: comp.windows.x
Subject: Re:  Stupid Imake question
Message-ID: <7271@spool.cs.wisc.edu>
Date: 4 Mar 89 15:30:18 GMT
References: <8902282128.aa17018@SPARK.BRL.MIL>
Sender: news@spool.cs.wisc.edu
Reply-To: solomon@gjetost.cs.wisc.edu (Marvin Solomon)
Organization: U of Wisconsin CS Dept
Lines: 119

In article <8902282128.aa17018@SPARK.BRL.MIL> phil@BRL.MIL (Phil Dykstra) writes:
>Confusion over the use of imake is common enough that this is worth
>spelling out:
>
>1) Get a copy of ximake.sh in the MIT core distribution under
>   util/scripts/ximake.sh.
>
>2) Install it as /usr/bin/X11/ximake (or wherever your binaries are)
>   and make it executable.
>
...
>
>One limitation of the above is that you do need to have access to
>the source tree on the machine you run imake from (since it gets
>the imake macro files out of util/imake.includes and links to the
>libraries and header files in the source tree).  The MIT folks have
>said that R4 should remove this restriction.
>
In general, I find that the R3 distribution depends on altogether too
must stuff scattered around in the source tree.  I hope that the "MIT folks"
will try to clean up this situation as much as possible.

In somewhat more detail, here's what I mean.  We have to build X for
several different architectures.  We keep the source tree on an NFS server.
If I want to build binaries for a VAX, I mount the source tree
on a VAX and do a "make world" there.  Unfortunately, somebody else
might be trying to build a Sun version at the same time.
The util/scripts directory has a lndir.sh script designed to solve just
this problem.  It allows me to make a "shadow" copy of the source tree,
with symbolic links to all the sources.  Then I can do my "make" without
interfering with anybody else.

Now consider this scenario:
I want to compile a particular client for the VAX, perhaps because I'm
trying to enhance it or fix a bug, or perhaps I just got the source for
it off the net.  To take a particularly simple example, consider xfd.
Here's the whole Imakefile:
	LOCAL_LIBRARIES = $(XLIB)
			   SRCS = xfd.c wsimple.c
			   OBJS = xfd.o wsimple.o

	ComplexProgramTarget(xfd)
Admirably simple and seemingly very portable.

I'd prefer not to build a shadow of the entire X source tree, just the source
dir for the particular client, so I make a copy of $(TOP)/clients/xfd.
First I need to make an initial Makefile.  I can use ximake, assuming:
	ximake is in "wherever my binaries are", and
	imake is in "wherever my binaries are".
By default, neither of these is true.  Well, I move ximake to /usr/local/bin
(or whatever) get a version of imake compiled for machine M (for the time
being, we'll ignore how I do that) and put it in /usr/local/bin, and then
type "ximake /X11R3".  Then I type "make -n".  I get
	cc -O -I/X11R3   -c xfd.c
	cc -O -I/X11R3   -c wsimple.c
	Make:  Don't know how to make /X11R3/lib/X/libX11.a.  Stop.

What's the problem?
The problem is that generated Makefile contains the line
	xfd: $(OBJS) $(LOCAL_LIBRARIES)
where $(LOCAL_LIBBARIES) is bound to $(XLIB), which ultimately resolves
to $(TOP)/lib/X/libX11.a.  The Makefile is trying to pull in the X library
from the source tree.  That library was previously built, installed, and
erased ("make clean").  Even if $(XLIB) exists now, it probably is a version
compiled for the wrong target architecture.  What do I do now?  Well I could
go make a copy (or shadow) of the whole source directory, do a global
build, take a nap while I'm waiting, wake up to find out that my local
disk has overflowed :-), etc.  Or I can change the first line of the
Imakefile to
	SYS_LIBRARIES = -lX11.
(So much for not having to edit the Imakefile!)
After I rerun ximake, make works successfully:
	cc -O -I/X11R3   -c xfd.c
	cc -O -I/X11R3   -c wsimple.c
	rm -f xfd
	cc -o xfd xfd.o wsimple.o  -O -lX11  
If however, I try "make Makefile" instead of "ximake", I get
	/X11R3/util/imake/imake -TImake.tmpl -I/X11R3/util/imake.includes \
		-s Makefile -DTOPDIR=/X11R3
Which bombs because /X11R3/util/imake/imake is compiled for a Sun.
(If the source tree is "clean", there won't be any such executable.
"make Makefile" will helpfully cd to /X11R3/util/imake and do a "make" there,
so that my friend who's trying to compile something for a Sun will have
his "make Makefile" bomb).  Similar problems arise with "make depend", which
tries to use $(TOP)/util/makedepend/makedepend.

If I choose a more complicated client, things are worse.
For example, some Imakefiles expect to find mkfontdir or bdftosnf (the
font compiler) somewhere deep in the bowels of the source tree.
The handing of include files is also a bit of a problem.  $(TOP)/X11 has a copy
of X.h so that a client that contains
	#include <X11/X.h>
can be compiled with the flag -I$(TOP).  But only some of the include files
are in $(TOP)/X11.  (Toolkit includes, for example, are not).  If the
includes files you need all happen to have been installed in /usr/include/X11,
you're ok, but I've run into situations where that isn't so.
Finally, if any client should happen to use any "contributed" anything, all
bets seem to be off.

What's the solution?  I don't pretend to have a neat solution, but it seems
to me that the standard installation procedure should "install" *everything*
that is generated in one directory but used somewhere else.  Things that
are not generally useful to "ordinary X users" (whatever that my mean)
could be put in a special directory set up for the purpose. Executables
that are machine-specific should be separated out from other things (shell
files, includes, etc).

Finally, looking back over this message, I'm afraid it may sound too
negative.  I think the MIT folks have done a remarkable job of simplifying
configuration of such a large and complex system, but there's still a lot
of polishing needed.  Maybe "cake" is better way to do it, but I won't
believe that cake makes all the problems go away until I see it used to
maintain a system that's as complicated--and needs to be ported to as large
a variety of environments--as X.
	Marvin Solomon
	Computer Sciences Department
	University of Wisconsin, Madison WI
	solomon@cs.wisc.edu
	...seismo!uwvax!solomon