Date: Tue, 5 Jul 2011 16:12:14 -0400 From: Ed Maste <emaste@freebsd.org> To: Alexander Kabaev <kabaev@gmail.com> Cc: freebsd-hackers@freebsd.org, Robert Millan <rmh@debian.org> Subject: Re: [PATCH] __FreeBSD_kernel__ Message-ID: <20110705201214.GA31647@sandvine.com> In-Reply-To: <20110705140527.17362ed5@kan.dnsalias.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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? -Ed Maste
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110705201214.GA31647>