Date: Thu, 1 Feb 96 10:56:47 MET From: Greg Lehey <lehey.pad@sni.de> To: pst@cisco.com (Paul Traina) Cc: hackers@FreeBSD.org, ports@FreeBSD.org Subject: Re: Another Pentium gcc patch, -D__FreeBSD__=2 -Dbsd4_4 Message-ID: <199602011000.LAA06728@nixpbe.pdb.sni.de> In-Reply-To: <199602010750.XAA11280@puli.cisco.com>; from "Paul Traina" at Jan 31, 96 11:50 pm
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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. I think we need to look back and decide what we're trying to do here. I don't have the original message (>>), but I believe it was you who wrote it. You said: "There's a well defined way to find out what version of the OS you're running under." Grouping all versions of FreeBSD, NetBSD and BSD/OS doesn't achieve this. Also, the fact remains that you're at the mercy of the correct installation (and contents :-) of sys/param.h. > 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. Agreed, defining the operating system version in param.h is closer to the truth than defining it in the compiler. But be aware that in gcc, the definitions are really in (mumble)/specs, a text file which you can modify. However, if we're going to talk about STANDARDs, it's about time that we thought out a better way. Most usage of #ifdef BSD and friends isn't to find out whether the target system is running BSD, it's a help to guess whether a certain specific feature is available. I've seen some really bad misassumptions based on this feature. What we really need is to specify (in sys/param.h, if you think it appropriate) which features the system has. To make this worthwhile, though, every flavour of UNIX would have to agree, and I don't see that happening. > I know, it's a pain in the ass to use the method I mentioned (see quote > above), but it's correct. This I debate. > 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. It looks like we'll have to remain in disagreement, unless I can convince you. There is *no* portable method. I suppose, though, I could agree that defining BSD4_4 is as much of a crock as everything else: my original message drew attention to the date code method of recognizing FreeBSD (only). A completely portable method would be one which requires no modification of existing sources, a reasonably portable method would require minimal changes, etc.--not just on FreeBSD, but on all platforms. Any method which requires changes to the majority of the source code ported to a particular platform is not portable. > I don't like it either, but I live with it. Well, I live with it too :-) But, like you, I don't like it. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602011000.LAA06728>