Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!nntp.coast.net!news.kei.com!news.mathworks.com!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!uunet!in1.uu.net!192.89.123.24!nntp.inet.fi!news.funet.fi!news.abo.fi!not-for-mail
From: mandtbac@news.abo.fi (Mats Andtbacka)
Newsgroups: comp.os.linux.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.misc
Subject: Re: Linux vs BSD
Followup-To: comp.os.linux.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.misc
Date: 29 Jan 1997 13:57:26 GMT
Organization: Unorganized Usenet Postings UnInc.
Lines: 60
Distribution: comp
Message-ID: <5cnl06$ket@josie.abo.fi>
References: <32DFFEAB.7704@usa.net> <5c39sk$ddl@troma.rv.tis.com> <5c8jlm$50u@cynic.portal.ca> <5c9444$9vq@lace.colorado.edu> <5c98sl$gbn@cynic.portal.ca> <5ckluo$mbl@josie.abo.fi> <32EE6127.41C67EA6@FreeBSD.org>
Reply-To: mandtbac@abo.fi
NNTP-Posting-Host: zaurak.abo.fi
X-Newsreader: TIN [UNIX 1.3 950520BETA PL0]
Xref: euryale.cc.adfa.oz.au comp.os.linux.misc:155589 comp.unix.bsd.bsdi.misc:5833 comp.unix.bsd.misc:2186
Jordan K. Hubbard, in <32EE6127.41C67EA6@FreeBSD.org>:
>Mats Andtbacka wrote:
>>yes, that's basically the arrangement. whether or not this is a good
>>thing depends, i suspect, on taste: i would claim that the *BSD
>>concept of one "make" in one tree does everything, while certainly
>>convenient, is more suitable to people somewhat afraid of their
>>compiler. less, after all, to compile, or so it appears to the person
>>just typing one "make".
>Ooh, that was just too simplistic an assumption to let pass by.
i don't mind being corrected. much.
[...]
>BSD make, at the expense of a few blatant assumptions about where its
>macro files live (/usr/share/mk), does a lot to provide consistent build
>framework for the sources under its care - if you want to compile the
>entire system at optimization level of 03, or without debugging
>information, or with every tool which was formerly linked shared now
>static (just to name a very small number of possibilities), it's a
>trivial command line option.
well, great. but what if i don't want it *all* done the same way, just
one utility linked differently from the others and some stuff
optimized less (since i care more about the size of my vi than its
speed) and others more? that's what i meant with configuration, not
changing the global defaults for everything.
which, of course, is not meant to slight the advantage of being able
to change those defaults easily, just that they're not always
necessarily useful.
[...]
>BSD Makefiles tend to be extremely concise as a result of this and very
>easy to read.
...and just a wee bit nonstandard, at times...
(okay, cheap shot, there is no makefile standard, i know. you probably
know what i mean in any case...)
>I've done some positively facinating stuff with GNU make,
>and I'd never say it wasn't a powerful alternative, but "concise" is
>never a word I've applied to the GNU makefile for any tool integrated
>with a large system (it's easy to make small gmake files, yes, but I'm
>talking about what happens once you add all the "knobs and levers").
very true indeed - i've seen imake autogenerate some makefiles shorter
than some handwritten ones for GNU make.
but so what? i, for one, care a lot more about how well the thing
works in the end than about its size. big makefiles *might* be harder
to handle - or, if they're properly written, they might not. extremely
short makefiles indeed can be unmanageable, if they were whipped up in
ten minutes around 2 A.M. some Saturday morning - i've seen a few
miniature horror stories like that.
--
"...it's all wrong
but it's alright..." -- Clapton