Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 08 Jan 1997 18:55:14 -0700
From:      Warner Losh <imp@village.org>
To:        asami@cs.berkeley.edu (Satoshi Asami)
Cc:        m230761@ingenieria.ingsala.unal.edu.co, ache@nagual.ru, ports@freebsd.org
Subject:   Re: Niklas Hallqvist: archivers/hpack.non-usa.only 
Message-ID:  <E0vi9i6-0003xU-00@rover.village.org>
In-Reply-To: Your message of "Wed, 08 Jan 1997 16:19:23 PST." <199701090019.QAA02492@silvia.HIP.Berkeley.EDU> 
References:  <199701090019.QAA02492@silvia.HIP.Berkeley.EDU>  

next in thread | previous in thread | raw e-mail | index | archive | help
In message <199701090019.QAA02492@silvia.HIP.Berkeley.EDU> Satoshi Asami writes:
: (1) Change the port in a way that is compatible with other operating
:     systems (*) using BSD or __44bsd__ (see David O'Brien's mail), and
:     send a patch to the author.  Because of (*), the change is more
:     likely to be accepted, and the patch can be deleted in the next
:     release.

I like this the most...

: (2) Protect all the changes with __FreeBSD__, and send a patch to the
:     author.  The patch is less likely to be accepted than (1) but at
:     least it's not intrusive WRT other OS's so there is a chance to be 
:     accepted.  When OpenBSD guys come along, we change some of them to 
:     __FreeBSD__ || __OpenBSD__.

I like this less.

: (3) Just change the ports to compile on FreeBSD.  Don't send the
:     changes back to the author.  The port may or may not work with the
:     next release.  However, this port has a better chance to work on
:     OpenBSD than (2).

I don't like this.

: (4) Same as (1), but don't send back the patch to the author.  See
:     disclaimer on (3).

Nor this...

: What does this mean?  Not much, I don't think we can make a firm
: "policy" on this, these are just for people to keep in mind.  One
: thing to note is that (2), if we you don't send the patch to the
: author, is a clear no-winner.

Agreed.

The other thing you can do is say something like:

#if defined( unix ) || defined( __unix__ ) || defined( __unix )
#include <sys/param.h>
#endif

....

#if defined( BSD ) && BSD >= 199xxx
/* Whatever */
#endif

I would argue that BSD being defined is only useful on unix machines,
so this should be acceptible to most authors.

I agree that this means there is much more work that needs to happen
for each machine that otherwise would have happened.

I'm not sure I like adding a new __bsd44__ macro definition.
Something about it strikes me as wrong, but I can't place my finger on
it.

A question of policy:
	Would it be acceptible to have the __FreeBSD__ || __OpenBSD__
case in the tree as a transitory phase between the current abuses of
__FreeBSD__ and the future where such abuses don't happen?

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0vi9i6-0003xU-00>