From owner-freebsd-hackers Wed Feb 5 11:19:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA03389 for hackers-outgoing; Wed, 5 Feb 1997 11:19:33 -0800 (PST) Received: from relay.nuxi.com (nuxi.ucdavis.edu [128.120.37.176]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA03372; Wed, 5 Feb 1997 11:19:23 -0800 (PST) Received: from dragon.nuxi.com (reqf-022.ucdavis.edu [128.120.253.142]) by relay.nuxi.com (8.8.4/8.6.12) with ESMTP id LAA25441; Wed, 5 Feb 1997 11:19:26 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.8.4/8.7.3) id LAA07180; Wed, 5 Feb 1997 11:19:14 -0800 (PST) Message-ID: <19970205111913.YS06559@dragon.nuxi.com> 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 References: <19970205003343.YB13323@dragon.nuxi.com> <19970202135048.PN07710@dragon.nuxi.com> <199701280143.RAA06503@freefall.freebsd.org> X-Mailer: Mutt 0.59-PL19 Mime-Version: 1.0 Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 In-Reply-To: ; from Warner Losh on Feb 5, 1997 08:16:03 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 . 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 (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)