casey@lll-crg.llnl.gov (Casey Leedom) (01/13/89)
I've made a lot of fixes to the contributed software in X.V11R3 mostly to do with simplifying and integrating configuration and installation. I haven't posted any of them prior to this because I felt it was more important that I get my fixes to the core software out. But it seems reasonable to post them now with my recent suggestion about qualifying future acceptance of contributed software on presense on an Imakefile. Even more specifically, I believe that all contributed software should be put to the following test by the X Window System group before acceptance: % edit Imakefile % make Makefile TOP=... % make % make install % make install.man % make clean There are obviously some programs which are written for specific architectures (Sun, Vax, etc.), but they should at least compile and install on that machine! Note also that the edit phase on Imakefile should be as simple as possible. No package should require more than simple configuration choice editing of Imakefile and at most one other file. You may think this overly restrictive, but as David Tillbrook said, "Why should I waste my time with your software if you weren't ready to finish it?" Installation configuration documentation and control files are part of any project. If you haven't done the work to make that documentation and your control files work, the software isn't finished. I'll take this opportunity to complement the X Window System people again on the fine job they've done along these lines in the core distribution. If we can only get the contributed software up to the same standards the whole task of dealing with X will be a lot simpler and more pleasant. The following notes will cover: Skeleton Imakefiles/Makefiles in all the contrib interior nodes clients/xbgsun clients/xcalendar clients/xdvi clients/xfig clients/xlock clients/xmessage clients/xperfmon clients/xplaces clients/xpref clients/xstring clients/xtools fonts/utils/bdf2vf fonts/utils/bdf2vf fonts/utils/bdfresize fonts/utils/mac2bdf fonts/utils/vf2bdf fonts/utils/xfed fonts/utils/xfed.ncd windowmgrs/awm windowmgrs/twm Casey
casey@lll-crg.llnl.gov (Casey Leedom) (01/14/89)
| From: Dave Lemke <lemke@Sun.COM> | | > Even more specifically, I believe that all contributed software should | > be put to the following test by the X Window System group before | > acceptance: | > | > % edit Imakefile | > % make Makefile TOP=... | > ... | > | > You may think this overly restrictive ... | | Yes, i do thinks its overly restrictive, and for the following reasons: | | 1) I hate imake. I realize the rest of the world loves it, and compared | to raw make it is great. But it has far less power then Sun's | make. I'll say the same thing I said to David Korn with regard to his using AT&T's nmake: Are you ready to freely distribute Sun's new make? Of course not, nor could David Korn distribute nmake. (Just as an aside, the nmake available through the AT&T toolchest is not the same as that used by AT&T. It's a very early, buggy copy that's more likely to core dump than work.) The sources to make aren't freely available, but at least the program itself is widely available. Make put together with imake handle a lot of the deficiencies of raw make as you point out. Also, the entire X distribution is done using imake. | 2) The apps & demos I write and have contributed have been developed | in our build environment for X11/NeWS. This means no imake, | so I have to rewrite the makefiles to deal with your proposed | restriction. You have to rewrite the Makefiles or the Imakefiles? I'm not clear on this point. I understand that if you're using Sun's make, you don't have any Imakefiles, but there's nothing in your point here that prohibits you from using imake to begin with. | 3) Most importantly, not everyone keeps the basic hierarchy around. | I sure don't. So if the libs are all moved to /usr/local/lib, | imake doesn't buy me much. This also leaves the user out in | the cold. The sys admin sets everything up in /usr/local, | and this neat new application comes across the net. The sys | admin has no time to set it up, so the user has to rewrite | the installation code to get it to build. | | I've probably spent as much time ripping apart imake produced Makefiles | as you have putting them together -- they just don't fit our src hierarchy. | | This isn't to claim that its a totally bad idea. Imake is a wonderful | solution to the current problem, but when comp.sources.x first decided | that you had to provide an Imakefile, I decided some of my code wasn't | going out on it, because I didn't have the time or the build environment | to test imake. And here you hit exactly the point I referred to in an earlier letter. The problem of dealing with compiling an application within the X source tree when all the libraries and include files are still in ../../.., etc. versus compiling either outside the tree or when everything's been installed and cleaned up - possibly with the source archived or on a different machine. Just how do you use imake and Imakefiles when all you've got are installed libraries and include files??? My suggestions to the X Consortium along those lines are: 1. install imake itself as part of the installation process into your BINDIR. 2. Provide a simple define, switch, whatever, to easily configure your Makefiles to compile within or outside the X tree ala: % make Makefile IMAKEDEFS="-DCompileWithInstalled" or some such. In fact, since most development is done with installed libraries, etc. I think that should be the default and the other should be an option. (IMAKEDEFS="-DMakeWorld"?) Casey
len@synthesis.Synthesis.COM (Len Lattanzi) (01/14/89)
In article <16592@lll-winken.LLNL.GOV> casey@lll-crg.llnl.gov (Casey Leedom) writes: : Just how do you use imake and Imakefiles when all you've got are :installed libraries and include files??? My suggestions to the X :Consortium along those lines are: 1. install imake itself as part of the :installation process into your BINDIR. 2. Provide a simple define, :switch, whatever, to easily configure your Makefiles to compile within or :outside the X tree ala: : : % make Makefile IMAKEDEFS="-DCompileWithInstalled" : :or some such. In fact, since most development is done with installed :libraries, etc. I think that should be the default and the other should :be an option. (IMAKEDEFS="-DMakeWorld"?) : :Casey What's wrong with having your own IMAKEINCLUDE environment variable with the following diff to Imake.tmplate 434c434 < TOP = TOPDIR --- > TOP = . 459,463c459,463 < XLIB = $(XLIBSRC)/libX11.a < XMULIB = $(XMUSRC)/libXmu.a < OLDXLIB = $(OLDXLIBSRC)/liboldX.a < XTOOLLIB = $(TOOLKITSRC)/libXt.a < XAWLIB = $(AWIDGETSRC)/libXaw.a --- > XLIB = /usr/lib/libX11.a > XMULIB = /usr/lib/libXmu.a > OLDXLIB = /usr/lib/liboldX.a > XTOOLLIB = /usr/lib/libXt.a > XAWLIB = /usr/lib/libXaw.a This is unix specific but you get the idea. -Len Len Lattanzi (len@Synthesis.com) <{ames,pyramid,decwrl}!mips!synthesis!len> Synthesis Software Solutions, Inc. 1 408 991 0367 292 Commercial Avenue, Sunnyvale, California 94086
mtr@mentor.cc.purdue.edu (Miek Rowan) (01/14/89)
In article <11166@mips.mips.COM>, len@synthesis.Synthesis.COM (Len Lattanzi) writes: > > XLIB = /usr/lib/libX11.a > > XMULIB = /usr/lib/libXmu.a > > OLDXLIB = /usr/lib/liboldX.a > > XTOOLLIB = /usr/lib/libXt.a > > XAWLIB = /usr/lib/libXaw.a Why not just use USRLIBDIR here - then it could go to any site. The change is just from the SRC macro to the DEST macro. It is simple. mtr