Date: Wed, 5 Feb 1997 11:19:13 -0800 From: obrien@NUXI.com (David O'Brien) To: imp@village.org (Warner Losh) Cc: freebsd-ports@FreeBSD.ORG (FreeBSD ports list), hackers@FreeBSD.ORG Subject: Re: conditionally including <sys/param.h> Message-ID: <19970205111913.YS06559@dragon.nuxi.com> In-Reply-To: <E0vs94u-0000u5-00@rover.village.org>; from Warner Losh on Feb 5, 1997 08:16:03 -0700 References: <19970205003343.YB13323@dragon.nuxi.com> <19970202135048.PN07710@dragon.nuxi.com> <199701280143.RAA06503@freefall.freebsd.org> <Pine.OSF.3.95q.970127210526.2115E-100000@uplink.eng.umd.edu> <E0vrw2G-0000I7-00@rover.village.org> <E0vs94u-0000u5-00@rover.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh writes: > In message <19970205003343.YB13323@dragon.nuxi.com> David O'Brien writes: > : I'm just trying to find something that will cover all the 4.4BSD derived > : OS's. What are the big divergances from each other that __44bsd__ > : wouldn't cover (from an application standpoint)? Remember I'm trying to > : catch things like sys_errlist[], termios, /var/mail, /usr/sbin/sendmail, > : etc > > Better to include sys/param.h, from a portability standpoint, and > check to see if BSD is defined and larger than a certain value. The > hard part is knowing if sys/param.h will be there. RIGHT. That is *why* I want __44bsd__, to know it is safe to included <sys/param.h>. I'm not saying __44bsd__ has to be a replacement for the BSD macro. Although for the easy stuff, why not. On a side note, the BSD macro isn't that helpful. I know of few people that really know if a feature we have has been around since Net/2, or 4.4Lite. So most people take a wild stab at it. So would __44bsd__ be any worse? > It would be better to find a foolproof way of knowing when sys/param.h > is available (or at least when it generally isn't). Right, which is what I am trying to do. > Most of the examples that you sighted can be handled better by other > means. Don't declare sys_errlist at all, rather use strerror() or > #include <errno.h> (which is fairly standard). Don't use hard wired > path names, but rather the standard ones defined in pathnames.h. Remeber what I'm trying to do here, this is for the ports collection. I'm trying to solve a problem I come across quite often in making a port. I don't think I can get an author to accept that big of a change to his code. With your solution, I would have to worry that some Unix doesn't have the macro that I want to use from pathnames.h. If _I_ where writing the application/package, then things would yes be a little different. > You'll likely have to have a fallback for that strategy as well. > Also, as time moves forward, some new systems will adopt parts of the > 4.4 tree. Do you really want to have things like: > #if defined(__bsd44__) || (defined(SOLARIS) && SOLARIS >= 207) ... > in the sources? They quickly get out of hand. When other Unixes took parts from BSD in the past, they dont' define our macro. System V to my knowledge (which took many things from BSD), doesn't define BSD. So there is little to no reason to expect the above to happen. > Many of the ports have 2-3 lines of ifdefs to include stdlib.h, when > instead they should have a single #ifdef __STDC__ in its place. Because, GCC will define __STDC__ because the compiler can handle it. BUT that doens't mean GCC found stdlib.h when it fixed up the headers. GCC on SunOS defines __STDC__, but you will find it's native headers (which GCC uses), aren't. > Had BSD 4.4 come out with this symbol, things would be a little > different. However, it didn't think that it would be worth the > portibility hassles at this point, since it would take time for this > symbol to propigate to all flavors of BSD. 2.2 is almost out the > door, OpenBSD 2.0 is on the streets (and will be for a while). Netbsd > 1.2 is also on the streets and likely will be for a while too. > > I guess I'm just showing my years of riding heard on the OI/uib source > tree which was generally portable to the point that the compile time > (45 minutes to an hour) usually dominated the porting time (well, and > sometimes it was the licenese manager third party code too). > > Warner -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970205111913.YS06559>