Re: proposal: inetd improvements.

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> 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
> portable.

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
some mechanism.

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
systems without.

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