Date: Sat, 9 Jul 2011 23:06:28 -0600 From: Warner Losh <imp@bsdimp.com> To: Ed Maste <emaste@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org, Robert Millan <rmh@debian.org> Subject: Re: [PATCH] __FreeBSD_kernel__ Message-ID: <005E93BB-0DD4-495A-80E1-E6263C04EB17@bsdimp.com> In-Reply-To: <20110705201214.GA31647@sandvine.com> References: <CAOfDtXPUxQO1zbnxh8sh%2By7g=d8QaH2svYtEQJ06L4d%2BQKG8VA@mail.gmail.com> <20110702193724.5c55a6c9@kan.dnsalias.net> <20110703020827.GA5763@sandvine.com> <CAGH67wQAv4Tf8HjccN2GZzgD2u1ZrORABtGehxXjeg109%2BRNWQ@mail.gmail.com> <20110703103531.4a553271@kan.dnsalias.net> <CAOfDtXOcfbNw6St5CMN4GB_psf8hZEV=hpL4q3mmQXqWeLmqXQ@mail.gmail.com> <20110705140527.17362ed5@kan.dnsalias.net> <20110705201214.GA31647@sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I know this is a little late, but... On Jul 5, 2011, at 2:12 PM, Ed Maste wrote: > On Tue, Jul 05, 2011 at 02:05:27PM -0400, Alexander Kabaev wrote: > >> I agree with all of the above reasons, but none of them change the fact >> that __linux__ is used left and right to identify both kernel and >> userland environments just as __FreeBSD__ is. You choose to disable >> __FreeBSD__ in GNU/kFreeBSD presumably because it makes your life >> porting software easier and are asking FreeBSD project to cope with >> the decision. This breaks compiles of new software with older >> compilers than do not define the macro, takes __FreeBSD__ out of >> symmetry with __linux__ and other similarly defined platform macros >> and forces a race to update every other compiler out there to follow >> the suit. I fail to see the benefits out-weighting the drawbacks in >> this scenario. > > There are two separate issues here - the macro itself, and where it's > defined. > > On the topic of the macro itself, __FreeBSD__ implies something about > the kernel and the libc, and it used to be the same case for __linux__. > This became broken for __linux__ once people started combining a Linux > kernel with other than glibc, and it would break if those combining > the FreeBSD kernel with another libc defined __FreeBSD__. > > (A note on terminology - some may dislike the "GNU/" name for various > reasons, but either way their project is properly called "Debian > GNU/kFreeBSD." I'll refer to it as "kFreeBSD" here for brevity though, > since the kFreeBSD part is the unique aspect of this project vs other > Debian ports, and the full name is rather awkward to type.) > > kFreeBSD can't define __FreeBSD__, since it will break any existing > software that uses that to infer something about the libc in use. So, > that project had a choice; they could have created a new macro > __Debian_GNU_kFreeBSD__, say, that indicates the kernel and libc in use. > However, defining __FreeBSD_kernel__ (and __glibc__ presumably) makes > more sense, and actually reduces the porting effort for both them and > the FreeBSD porters. Any effort on porting software to the FreeBSD > kernel done by either project is then applicable to the other. If > kFreeBSD project members make a change to get some piece of software > working on a FreeBSD kernel and then gets that change commited upstream > we can take advantage of that work without any additional effort on our > part. I think we should define this. > On the topic of where such a macro should be defined I originally had > no strong opinion. However, valid points have been raised about > compiling software for FreeBSD using compilers that are not the one in > the base system (from ports or otherwise, and GCC or otherwise). This > I think is a very valid point and one that would make me lean towards > defining the macro in sys/param.h. How workable is it to #include > sys/param.h to pick up the macro where needed? Why can't the other compilers conform to the new standard instead? Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?005E93BB-0DD4-495A-80E1-E6263C04EB17>