[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: proposal: inetd improvements.
>> Well, IMO autoconf is not an improvement. [...]
> Let us take the recent addition of getline(3) to NetBSD libc. I am
> curious as to how you would automatically take advantage of it, yet
> build on older NetBSD systems without it.
As a software author? I wouldn't, actually. I'd either write for
systems that have it, write off portability to those that don't, and
just use it - or I'd write assuming its nonexistence, and, if I need
the functionality, provide it in my own code.
> Bonus points for making this decision user selectable and be fairly
If I wanted that, there are two main alternatives I'd take. The first
would be to #ifdef as appropriate and include something like "turn on
-DHAVE_GETLINE in the Makefile if you want to use getline(3)" in the
build documentation; the other would be to have a foo-getline.c and a
foo-nogetline.c and instructions to use whichever one you prefer by
I don't do either one much; I don't want this very often.
> Then repeat N times for each OS specific features you want to take
> advantage of for whatever reason.
Right. That's one reason I write code assuming the presence of various
things and then provide workarounds or fallbacks or whatever for
systems that don't have the things - or not, if I judge the portability
loss to be a lower price than the workaround, fallback, or whatever.
To pick two examples: (1) I write assuming the presence of funopen()
and friends a la a Torek stdio; for building on Linux, I have a
liblinuxcompat which provides an emulation using fopencookie(). (It's
a partial emulation, but close enough for lots of my code.) (2) I
write assuming labeled control structure in the compiler; for building
on systems where I haven't ported my LCS patches to the compiler, or
just haven't replaced the compiler with a build supporting LCS, I have
a program to be run over .i files. And as a third example, of a case
where I'm content to write off the portability loss, I write assuming a
prototype-capable compiler and don't bother with workarounds for
I do not mind assuming a minimal level of competence on the part of the
person trying to compile the code. I have yet to see _anything_ try to
satisfy everybody and not end up satisfying nobody (or occasionally
just almost nobody); my position is that if you aren't competent to,
for example, determine whether your system has getline(3) and to turn a
define on or off in the relevant place, you shouldn't be trying to
build the software; you should be using someone else's binaries.
(Well, at least, if your goal is just to get it running. Attempting
things beyond your skill and/or knowledge is perfectly reasonable when
done knowingly in an attempt to increase that skill and/or knowledge.)
Oh, that brings up another beef I have with autoconf-generated
configure scripts: they sometimes even end up looking for things with
no relevance whatever to the software. I've seen configure scripts
trying to detect things that don't affect anything. Literally: I look
at the #define-or-#undef generated by configure, search, and find it
affects absolutely nothing. I haven't seen it often, both because I
generally avoid configure-style software and because when I do run into
it (as with the examples on that blah post, at least some of which I
ran into at work, ie, because I was being paid to) I usually don't go
through the list of things being probed to determine which ones are
reasonable and which ones aren't - but it's happened.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |