I forgot another good example of portability *mostly* minus ifdef, mainly
plan9ports. This is the full set of plan 9 tools, including graphics tools
like the rio window manager, and it's pretty much ifdef-free.
I just did a quick grep for ifdef and it's basically
ifdef cplusplus
in some include files, which seems unavoidable nowadays, and of course
anything imported from elsewhere has the usual pile of ifdefs.
the configure script is just
echo read the README file
same for Makefile.
To build, you just run an INSTALL script which builds it all. Compilers are
fast. Makefile errors are avoided by just building it all, each time.
Would that the gnubin tools had learned these lessons.
On Wed, Jan 4, 2017 at 6:52 AM David <david(a)kdbarto.org> wrote:
From: "Doug McIlroy"
<doug(a)cs.dartmouth.edu>
Subject:Re: [TUHS] Mac OS X is Unix
keeping the code I work on portable between Linux
and the Mac requires
more than a bit of ‘ifdef’ hell.
| Curmudgeonly comment: I bristle at the coupling of "ifdef” and
"portable".
| Ifdefs that adjust code for different systems are prima facie
| evidence of NON-portability. I'll buy "configurable" as a descriptor
| for such ifdef'ed code, but not "portable".
| <snip>
| "Ifdef hell" is a fitting image for what has to be one of
| Unix's least felicitous contributions to computing. Down
| with ifdef!
| Doug
Doug makes a very good point about ifdef hell. Though I’d claim that it
isn’t even “configurable” at some level.
Several years ago I was working at Megatek, a graphics h/w vendor. We were
porting the X11 suite to various new boards at the rate of about 1 a week
it seemed. Needless to say the code became such a mishmash of ifdef’s that
you couldn’t figure out what some functions did any longer. You just hoped
and prayed that your patch worked properly on the various hardware you were
targeting and didn’t break it for anyone else. You ran the unit tests, if
they passed you pushed your change and ran an hid under a rock for a while
until you were sure it was safe to come out again.
David