Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Jan 1996 23:50:36 -0800
From:      Paul Traina <pst@cisco.com>
To:        Greg Lehey <lehey.pad@sni.de>
Cc:        hackers@FreeBSD.org, ports@FreeBSD.org
Subject:   Re: Another Pentium gcc patch, -D__FreeBSD__=2 -Dbsd4_4 
Message-ID:  <199602010750.XAA11280@puli.cisco.com>
In-Reply-To: Your message of "Thu, 01 Feb 1996 08:35:18 %2B0700." <199602010739.IAA25585@nixpbe.pdb.sni.de> 

next in thread | previous in thread | raw e-mail | index | archive | help

  From: Greg Lehey <lehey.pad@sni.de>
  Subject: Re: Another Pentium gcc patch, -D__FreeBSD__=2 -Dbsd4_4
  >
  > I don't think our current gcc defines bsd4_4, I'm certain it shouldn't. :-)
  > There's a well defined way to find out what version of the OS you're runnin
>>g
  > under.
  >
  > #ifdef _HAVE_PARAM_H
  > #include <sys/param.h>
  > #endif
  >
  > #if defined(BSD) && (BSD >= datecode)
  > ...
  > #endif
  >
  > This gives us much finer grained control.
  
  How does this distinguish between BSD/OS, NetBSD and FreeBSD?  How
  does it distinguish between FreeBSD 2.1 and FreeBSD 2.2?  What this
  really tells you is what version of the compiler or header files you
  have.

The big mistake most porters make is they TRY to distinguish us from
NetBSD and BSD/OS.  Most "freebsd" distinctions are really 4.4 and later
distinctions and should use the BSD define.

That's why you should use the sys/param.h method, becuase it's what
everyone decided on as the STANDARD way to do this.  If you gratuitously
define bsd4_4 in the compiler and have programs rely on it, then you're
not doing anyone any favors.

I know, it's a pain in the ass to use the method I mentioned (see quote
above), but it's correct.

When you need to get finer grained than the standard, then use:
	__NetBSD__

	__FreeBSD__

	or __FreeBSD__==<majorver>

	or bsdi

  I think that the gcc *should* define bsd4_4 (or similar).  There's
  plenty of software out there which doesn't care which 4.4BSD-derived
  system you're running, and this would help, just like __386bsd__ used
  to be useful.

We're in violent agreement about your second sentence, disagreement about
your first.  The "portable" method has already been defined, and it's not
the one you chose.

I don't like it either, but I live with it.

Sorry,

Paul



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602010750.XAA11280>