becker@CS.ROCHESTER.EDU (Tim Becker) (01/18/89)
Lots of sites (besides mine) don't want to continually build every X
application that comes along from inside the X11 distributed src tree.
It could even be argued that from a s/w engineering point of view that
this is a *bad thing*. (Why even bother to install the libraries and
include files if none of the applications that get built uses them?!)
For these reasons, I think it's important that we get a way to build X
applications using Imakefile's that grab the installed libs/includes.
I've done a bit of work to get Imakefiles to work using installed
libraries and includes. However, I'd like a few changes from the X
workers at MIT to get it to work well. (Someone at MIT X staff, please
read this.)
My current incantation is an ximake shell script that is something
like this:
#! /bin/sh
IRULESRC=/usr/lib/X11/imake.includes
IMAKE=/usr/lib/X11/imake
$IMAKE -DCompileWithInstalled -TImake.tmpl -I$IRULESRC -s Makefile
I changed the Imake.tmpl to understand the CompileWithInstalled cpp
define. The first set of changes are nice and clean:
#ifdef CompileWithInstalled
XLIB = $(USRLIBDIR)/libX11.a
XMULIB = $(USRLIBDIR)/libXmu.a
OLDXLIB = $(USRLIBDIR)/liboldX.a
XTOOLLIB = $(USRLIBDIR)/libXt.a
XAWLIB = $(USRLIBDIR)/libXaw.a
#else CompileWithInstalled
XLIB = $(XLIBSRC)/libX11.a
XMULIB = $(XMUSRC)/libXmu.a
OLDXLIB = $(OLDXLIBSRC)/liboldX.a
XTOOLLIB = $(TOOLKITSRC)/libXt.a
XAWLIB = $(AWIDGETSRC)/libXaw.a
#endif CompileWithInstalled
Note that I don't have any new path variables or hardcoded paths here.
If the local installer defined UsrLibDir correctly (or didn't define
it at all - leaving the default for USRLIBDIR), the *correct* thing
will happen. The loader will get all the libs from the right
(installed) place.
The above change doesn't cover include files however. Here's what I
have now for this area:
#ifdef CompileWithInstalled
# this should work but does not because INCDIR is /usr/include/X11
# INCLUDES = -I$(INCDIR)
INCLUDES = -I/usr/include
#else CompileWithInstalled
INCLUDES = -I$(TOP)
#endif CompileWithInstalled
Note my comment in the code. The problem is that INCDIR is defined to
be the directory where the header files are to be installed. Yet,
most of the X11 application code gets these headers by writing
"#include <X11/xxxx>". Cpp will complain if I pass -I$(INCDIR)
because it can't find /usr/include/X11/X11/xxxx (note the X11/X11).
Before you say, "why bother with -I/usr/include when cpp will search
there by default", I must confess that I've not told the truth in my
examples above. I want to install things in
/usr/xxx/{bin,lib,include} - where xxx is "staff" for me (could be
"new", "local", etc). So, I have to bother with a -I.... on the
INCLUDES line in Imake.tmpl.
Since all the application code does "#include <X11/xxxx>", it won't
work to make INCDIR not end in "/X11". (I couldn't install the header
files in /usr/local/include, for example. It would have to be
/usr/local/include/X11.) So could we somehow specify INCDIR to not
include the /X11 on the end (but to assume it wherever it's used) or
could we have another variable that doesn't include the /X11 (so
INCDIR = $(INCLUDEDIR)/X11)? I don't like the first solution, but the
second isn't as ugly.
I think this is the only stickler keeping a non-src-hierarchy version
of imake from working. Can we figure out a way to fix this?
Tim.jim@EXPO.LCS.MIT.EDU (Jim Fulton) (01/18/89)
> Lots of sites (besides mine) don't want to continually build every X > application that comes along from inside the X11 distributed src tree. > It could even be argued that from a s/w engineering point of view that > this is a *bad thing*. There is no reason why people have to drop sources into their master tree. Anybody who does so is making more work for him- or herself. > However, I'd like a few changes from the X > workers at MIT to get it to work well. I'm in the middle of finishing up the restructuring of the imake config files that was begun in R3. It will be functionally similar to what you've done. I'm trying to reorganize things so that the X-specific stuff is more clearly identifiable. Jim p.s. If you want a name for the directory containing the X11 includes, use INCROOT (that's what R4 will use).
mao@blia.BLI.COM (Mike Olson) (01/19/89)
regarding the problem
#ifdef CompileWithInstalled
# this should work but does not because INCDIR is /usr/include/X11
# INCLUDES = -I$(INCDIR)
INCLUDES = -I/usr/include
#else CompileWithInstalled
INCLUDES = -I$(TOP)
#endif CompileWitInstalled
reported by tim becker, where INCDIR doesn't work because clients insist
on including <X11/*.h>, i solved the problem by using
INCLUDES = -I$(INCDIR) -I$(INCDIR)/..
this is suboptimal, but works.
i found the same problem with R3 -- almost no program (except the ones
developed locally) uses the installed versions of the libraries or header
files. rather than waste space, i did the equivalent of a "make install"
by hand, slinking everything from the install directories to the source tree.
that said, i think that MIT has done a first-rate job of release engineering
this time around. i remember the hair-pulling it took to get R1 and R2
installed. now, if the full distribution were less than eighty megabytes
of source code...
mike olson
britton lee, inc.
...!ucbvax!mtxinu!blia!mao
mao@blia.bli.comken@richsun.UUCP (Ken Marks) (01/20/89)
Regarding the problem of including <X11/foo.h> type header files and then linking with a path such as /usr/include/X11... Has anyone tried making a recursive link such as: cd /usr/include/X11 ln -s /usr/include/X11 X11 Works for me... Ken Marks