Return to BSD News archive
Xref: sserve comp.os.386bsd.apps:397 comp.sources.d:8227 gnu.misc.discuss:11054 comp.windows.x:57973 Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!network.ucsd.edu!mvb.saic.com!arizona.edu!cerritos.edu!news.service.uci.edu!hydra.acs.uci.edu!strombrg Newsgroups: comp.os.386bsd.apps,comp.sources.d,gnu.misc.discuss,comp.windows.x Subject: Re: 386BSD versions of sources... Message-ID: <2C8A6945.20403@news.service.uci.edu> From: strombrg@hydra.acs.uci.edu (Dan Stromberg) Date: 5 Sep 93 22:33:42 GMT Followup-To: comp.sources.d References: <CCB4ru.7K@sugar.NeoSoft.COM> <25iiki$m9a@umd5.umd.edu> <2C87CFEE.13991@news.service.uci.edu> <CCuz03.51@cyb.fred.com> Organization: University of California, Irvine Nntp-Posting-Host: hydra.acs.uci.edu Lines: 47 Please note, I've expanded the distribution considerably from just comp.os.386bsd.apps, but have directed followups to comp.sources.d - though this topic may soon be laid to rest. In article <CCuz03.51@cyb.fred.com> you write: >>>*flame on* >>>CONFIGURE SCRIPTS CONSIDERED HARMFUL [ My stuff about how nice GNU autoconf is, removed ] >Personally I reckon its a crying shame that Imake only comes with X. I >reckon its a great tool. The thing is, its approaching the problem from the >other direction; instead of the configure script having to try and figure out >where everything is, the Imake program tells it: "Well, I've got this, havn't >got that, I've got this but its in a wierd place". And that is, IMHO, the >way it should be done. Waell... I believe it's used with Kerberos out of the box, and comes in it's own archive sometimes... But regardless, there's nothing to stop you, and other folks, from extending imake to handle more system dependencies; it'd probably be better than the way things are done now... (like assuming all the world is unmunged BSD 4.2, or assuming that people installing packages would rather diddle the same details again and again, rather than play in the sand or develop their own code!) We differ significantly on the virtues of the two approaches, though. :) imake is certainly faster while you're building a package on an already-supported architecture, but I'd rather have the machine chugging on those details, than have to be fixing/extending people's imake templates on various systems. Why: When you come up against a new sort of system dependency, and wish to incorporate it's resolution into imake and/or autoconf, doing it for imake appears to require O(n) human labor, while doing it for autoconf is O(1) - where "n" is the number of architectures on which ya compile yer toys. As we continue to get more and more varieties of *ix out there, imake would seem to be prone to becoming more and more labor intensive to maintain, as time goes on. One may argue "well, I only use one architecture, so who cares about other people's templates?" Thing is, the people writing/maintaining your favorite software, may be saying the same thing.. Finally - I mean no major slam on imake, its authors, or its proponents. As I've already intimated, the folks who set it up took *ix portability a long way ahead.