jec@iuvax.cs.indiana.edu (03/01/89)
I have a question concerning the various packages that have been distributed on the net that use Imake. My question is basically how do I use Imake? Let's say that I unpack awm2 for instance since that was the last thing that I had this problem with. It includes an Imakefile file, so I guess that it uses Imake. I can type "imake" and it will complain about a missing template file: % imake 4: Can't find include file Imake.template imake: Exit code 1. Stop. What am I missing here? I've tried setting IMAKEINCLUDE to point to the right place and that doesn't seem to help either. Another thing is that the template file is called Imake.tmpl anyway. James Conley Indiana University Computer Science jec@iuvax.cs.indiana.edu
phil@BRL.MIL (Phil Dykstra) (03/01/89)
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. 3) To configure X software with an Imakefile simply say: ximake $XTOPDIR where $XTOPDIR is the location of the top of your X11 source tree (e.g. /usr/src/X11). This will generate a Makefile from the Imakefile. You can then run "make depend", "make", "make install", etc., just as with a normal Makefile. I went one step farther and edited the ximake script to default to the source tree location on my machine. Then you only have to say "ximake" to generate the Makefile. 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. For those of you that still avoid Imakefiles, I point out that you almost ALWAYS have to edit a Makefile to successfully install new software, but almost NEVER have to edit Imakefiles. Try it, you'll like it. - Phil <phil@brl.mil> uunet!brl!phil
kucharsk@uts.amdahl.com (William Kucharski) (03/01/89)
In article <8902282128.aa17018@SPARK.BRL.MIL> phil@BRL.MIL (Phil Dykstra) writes: >For those of you that still avoid Imakefiles, I point out that you >almost ALWAYS have to edit a Makefile to successfully install new >software, but almost NEVER have to edit Imakefiles. > >Try it, you'll like it. O.K., but I have a suggestion. When writing Imakefile entries (or Makefile entries, for that matter), STOP including labels like: LABEL = value and start writing them left-aligned, as in LABEL=value The reason for this is that SYSV make throws up if there is a space or tab before the label. Now, let me climb atop my soapbox for a moment... As X11 progresses, it is becoming less a BSD-ish product and more a BSD/SYSV or other UNIX product. If I may, could I ask that persons writing code for posting to comp.sources.x or those writing software to be destined for future "contrib" files TRY to follow the Makefile rule above? Thanks in advance. -- William Kucharski ARPA: kucharsk@uts.amdahl.com UUCP: ...!{ames,decwrl,sun,uunet}!amdahl!kucharsk Disclaimer: The opinions expressed above are my own, and may not agree with those of any other sentient being, not to mention those of my employer. So there.
meo@stiatl.UUCP (Miles O'Neal) (03/01/89)
In article <33500006@iuvax> jec@iuvax.cs.indiana.edu writes: > I have a question concerning the various packages that have been >distributed on the net that use Imake. My question is basically how do I >use Imake? The following is a script I came up with to make Imake work with the least typing. Modify directories as necessary. Note that this is an sh script. ----------------------- # imake - make a Makefile form an Imakefile. # invoke this from directory containing Imakefile. # no options BASEDIR=/usr/sti/X_dev/util IMDIR=$BASEDIR/imake IMIDIR=$BASEDIR/imake.includes $IMDIR/imake -T $IMIDIR/Imake.tmpl -I$IMIDIR -s Makefile ------------------------ -Miles gatech!stiatl!meo
raveling@vaxb.isi.edu (Paul Raveling) (03/02/89)
In article <33500006@iuvax> jec@iuvax.cs.indiana.edu writes: > > I have a question concerning the various packages that have been >distributed on the net that use Imake. My question is basically how do I >use Imake? The easiest way is with a script such as that provided in the X sources in util/scripts/ximake.sh. However, we had a minor problem with this script. We use a separate shadow tree as a build tree, with symbolic links to files in the original source tree. In part, we want to avoid modifying the original source tree files. The original script followed the symbolic link for Makefile back to the source tree and updated the wrong tree. To cure this we inserted these lines in the script & called it just ximake: 35a36,40 > if [ -f $what ]; then > cp $what $what.bak # Break symbolic link, if any > rm $what > fi > (Sorry, HP-UX doesn't include cdiff) Normal procedure to use it is... setenv xs <root directory of build tree> cd <directory where you want to do the Imake> ximake $xs Since it's short, I'll append the modified script to this message. ---------------- Paul Raveling Raveling@isi.edu ------------------------------------------------------------------------- : # # script to generate a Makefile from an Imakefile. Sometimes useful for # generating Makefiles for stuff outside the X sources. # progname=$0 xtop=$1 what=$2 if [ x"$xtop" = x ]; then echo "usage: $progname xsourcespath [whattomake]" exit 1 fi if [ x"$what" = x ]; then what="Makefile" fi if [ ! -d $xtop ]; then echo "$progname"": no such directory $xtop" exit 1 fi if [ ! -d $xtop/util -o ! -d $xtop/util/imake.includes ]; then echo "$progname"": no X configuration files under $xtop" exit 1 fi if [ ! -f Imakefile ]; then echo "$progname"": can't find `pwd`/Imakefile" exit 1 fi if [ -f $what ]; then cp $what $what.bak # Break symbolic link, if any rm $what fi echo "Making $what from Imakefile" PATH=$xtop/util/imake:$PATH \ imake -DTOPDIR=$xtop -TImake.tmpl -I$xtop/util/imake.includes -s Makefile $what
schwartz@shire.cs.psu.edu (Scott Schwartz) (03/02/89)
In article <8902282128.aa17018@SPARK.BRL.MIL>, phil@BRL (Phil Dykstra) writes: >Confusion over the use of imake is common enough that this is worth >spelling out: Note that this is because Imake is basically confusing, NOT because the people trying to use it aren't smart enough. >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). >For those of you that still avoid Imakefiles, I point out that you >almost ALWAYS have to edit a Makefile to successfully install new >software, but almost NEVER have to edit Imakefiles. ?? If the 2nd quoted paragraph is true, then the 3rd will almost never be true. Since 99 44/100 percent of the X11 installations either don't have the distribution source tree around, or have done a "make clean" in it, you not only have to edit the imakefile, but you have to decipher it to figure out what to edit. Not fun, not nice, and not worth it. The Right Way to do this is to use Larry Wall's configure program, so you never have to edit a makefile or anything else. >Try it, you'll like it. Sounds like a cigarette ad. In reality, the emperor has no clothes and Imake is quite a hassle. -- Scott Schwartz <schwartz@shire.cs.psu.edu>
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (03/02/89)
>> Confusion over the use of imake is common enough that this is worth >> spelling out: > > Note that this is because Imake is basically confusing, NOT because > the people trying to use it aren't smart enough. I'm sure Phil wasn't suggesting otherwise. Setting up configurations for new platforms will be much simpler in R4. Also, there will hopefully be better documentation on how to write Imakefiles. > Since 99 44/100 percent of the X11 installations either don't > have the distribution source tree around, or have done a "make clean" > in it, you not only have to edit the imakefile, but you have to > decipher it to figure out what to edit. Not fun, not nice, and not > worth it. Although it doesn't help now, the new configuration stuff doesn't require the source tree at all. > The Right Way to do this is to use Larry Wall's configure program, so > you never have to edit a makefile or anything else. Perhaps. In any case, you do need some sort of Makefile generator. Imake certainly isn't the best there is, but it is much better than nothing. It is simple to maintain, uses existing mechanisms as much as possible, is easy to port, allows configuration of both the build process and the software being built, is easy to tailor for machine-specifics, and (here's the tough part to swallow) is actually more palatable than eating garden slugs once you get used to it. More to the point, for all of these reasons (plus simple inertia) the core distribution uses imake. And so long as it does, we are going to encourage other people who are distributing X programs to use it as well because you have to have a common base. I'm sure that there are other solutions that meet all of the requirements mentioned above, would allow us to do hundreds things which we can't do already, wouldn't get snagged because of missing features on particular systems, wouldn't require massive amounts of work on our part, and would please everyone. But since I'm not Dionysus, I'm not going to go searching for one. Better the devil you know than the one you don't. Jim Fulton MIT X Consortium
becker@CS.ROCHESTER.EDU (Tim Becker) (03/02/89)
The Right Way to do this is to use Larry Wall's configure program, so you never have to edit a makefile or anything else. Have you ever had a problem with the configure program -- where you wanted to do something that wasn't built into the configure script? I've have to do it with rn and another package so far. LW's configure program doesn't *solve all ills* either. Sounds like a cigarette ad. In reality, the emperor has no clothes and Imake is quite a hassle. I finally bothered to write an ximake shell script that would turn an Imakefile into a Makefile without needing to keep the src tree around. I told it where to find the installed includes/libs. It's working great so far, no hassle. Really! Tim Becker. becker@cs.rochester.edu
solomon@gjetost.cs.wisc.edu (Marvin Solomon) (03/04/89)
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
sbb@esquire.UUCP (Stephen B. Baumgarten) (03/08/89)
In article <4331@psuvax1.cs.psu.edu> schwartz@shire.cs.psu.edu (Scott Schwartz) writes: >>Try it, you'll like it. > >Sounds like a cigarette ad. In reality, the emperor has no clothes and >Imake is quite a hassle. Alka-Seltzer, youngster.... They even ran it on those TVs without monitors -- oh, what were they called? -- radios, that's it! Before MTV, even. How about: "I'd walk a mile for imake" ? :-) -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." cmcl2!esquire!sbb | esquire!sbb@cmcl2.nyu.edu | - David Letterman