timr@labtam.oz (Tim Roper) (07/18/90)
In article <2767@uakari.primate.wisc.edu>, bin@primate.wisc.edu (Brain in Neutral) writes: > From article <MONTNARO.90Jul17154903@milkweed.crd.ge.com>, by montnaro@milkweed.crd.ge.com (Skip Montanaro): > > > > How about getting rid of Imake and using GNU make instead for R5? I've never > > gotten Imake to work properly, and always wind up translating Imakefiles > > into GNUmakefiles. > > Ahh .... no. Please don't. Imake is wonderful. It would, though, > ... > Or is it just me? I really like imake a lot, but found I have to invest > quite a bit of time trying to understand it before I was able to take > it and use it for my own projects. Is this unusual? > ... [This note is in support of Paul's view with a subjective assessment of my experiences with imake etc.] I found that investing a bit of effort in the imake learning curve is paying large dividends, eg. I can build most clients that come over the net with an Imakefile without changing anything (and I am using a System V unix). In fact when I want to build one that doesn't come with an Imakefile I find it easier to write an Imakefile than edit the Makefile. Having spent a significant proportion of "programming" time editing other people's Makefile's so that they would build on whatever system I was using at the time, I have found imake an overall win. -Tim.
bin@primate.wisc.edu (Brain in Neutral) (07/18/90)
From article <5005@labtam.oz>, by timr@labtam.oz (Tim Roper): > In article <2767@uakari.primate.wisc.edu>, bin@primate.wisc.edu (Brain in Neutral) writes: >> Or is it just me? I really like imake a lot, but found I have to invest >> quite a bit of time trying to understand it before I was able to take >> it and use it for my own projects. Is this unusual? > > [This note is in support of Paul's view with a subjective assessment of my > experiences with imake etc.] Well, while we're on the subject of imake... I've been thinking lately of how to be able to reuse configuration files for multiple projects that may or may not be related, without having to have a full set for each project (Imake.tmpl, site.def, Project.tmpl, Imake.rules, etc.) I've written up some scribblings about how this might be done; if anyone would like to read it and give me feedback, send mail. The problem I've tried to solve is this: how can the number of configuration files to be maintained be minimized and how can configuration files be shared among projects without sacrificing the ability to specify project-specific information as necessary? I freely admit that this may not even be a problem at all, i.e., that the standard X11R4 Imake.tmpl architecture might allow this somehow. But I couldn't figure out how to do it without making some changes. (The "Configuration Management in the X Window Sytem" document does hint at sharing the master template and the .cf files "among various development efforts", but it's no more than a hint.) Paul DuBois dubois@primate.wisc.edu
meo@rsiatl.UUCP (Miles ONeal) (07/21/90)
I have to speak in favor of imake. It was a pain to learn (any real doc, yet?), but no more than many other parts of unix when no doc was available from most vendors. But it's not THAT hard, and it certainly does, as Tim said, beat the flip out of trying to fix some of the whacko makefiles people use. Now, it COULD be made a little more general (or have the doc with it to say how to make it so) - the biggest problem I have with it is that it's so tied to the X distribution. (I know, I know, and I have as much (ha) time to do that as you do.) -Miles