[TUHS] Ifdef hell

[rminnich@gmail.com (ron minnich)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2317 bytes --]

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 at kdbarto.org> wrote:

> From: "Doug McIlroy" <doug at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170104/9102da4a/attachment.html>