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>