*BSD News Article 30970


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!spool.mu.edu!sol.ctr.columbia.edu!newsxfer.itd.umich.edu!gatech!swrinde!elroy.jpl.nasa.gov!decwrl!vixie!vixie
From: vixie@vix.com (Paul A Vixie)
Newsgroups: comp.os.386bsd.development
Subject: Re: Request to ``ports'' developers
Date: 27 May 94 22:05:27
Organization: Vixie Enterprises
Lines: 38
Message-ID: <VIXIE.94May27220527@office.home.vix.com>
References: <2s291q$pnl@meatball.rwwa.com> <2s37a4$mp9@pdq.coe.montana.edu>
NNTP-Posting-Host: office.home.vix.com
In-reply-to: nate@bsd.coe.montana.edu's message of 26 May 1994 22:19:48 GMT

As long as we're making pleas...

The "ports" I've seen were often extremely sloppy.  Rather than #ifdef 
something for "posix" or "ansi" or (BSD >= 199103), macros such as __bsdi__,
FreeBSD, and NetBSD were used.

When you add #ifdef's and code to a package, you should always use the least
specific macro that describes the feature you're depending on.  Don't say
"#ifdef __freebsd" (or whatever) if you're really just trying to control the
compilation of code which depends on a 4.4BSD (or BNR2, or Posix, or...)
feature.  Spend the extra time to figure out what the "domain" is of the
feature, and then add #ifdef's which will help _other_ people use the code,
not just the *BSD community.

The BSD macro is the most subtle thing we've got going.  It was defined as
"42" in BSD 4.2, "43" in BSD 4.3, something else in Reno and Tahoe, "199103"
in BNR2, and now in BSD 4.4 (and 4.4-lite), "199405" (I think -- someone
should check.)  If you are porting some public piece of code to a *BSD system,
you can do the world a huge favour by using #if's rather than #ifdef's and
comparing BSD against whatever constant describes the date of the BSD System
Interface your system conforms to.  Or, as I implied earlier, if some block
of conditionally compiled code will run on "any" POSIX system, use ``#ifdef
POSIX'' and then make that one of the macros that the Makefile defines on a
*BSD system.

And don't forget to send your patches back to the maintainer or author of the
package you ported!  Sometimes this person is hard to identify and often she or
he will be swamped with real work, or just recalcitrant about accepting patches
from outsiders.  But keep trying.

If everyone had followed these rules before 4.4-lite came out, most of the
previously ported software would "just work" now on the 4.4-lite derived 
systems.  Let's start off on the right foot this time, ok?
--
Paul Vixie
Redwood City, CA
decwrl!vixie!paul
<paul@vix.com>