*BSD News Article 20457


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.