On Mon, Nov 21, 2011 at 06:39:26PM +0100, Robert Millan wrote: > (replying with Debian hat this time) > > 2011/11/21 Kostik Belousov <kostikbel_at_gmail.com>: > > There are some implementations that > > use FreeBSD kernel, and which could potentially benefit from providing > > its own value for __FreeBSD_kernel. > > Actually, we wouldn't be able to provide a different value for the > macro (whatever its name). Our compiler simply doesn't know which > version of the kernel it is building for. Only the headers do, but if > we define it in the headers we'd just use the FreeBSD definitions. > > Our compiler defines __FreeBSD_kernel__ as an empty macro, I don't > expect this will change because unlike with FreeBSD, on Debian there > are strong technical limitations to making it a number. > > If __FreeBSD_kernel__ is to be defined in FreeBSD land, may I suggest > that it is defined as an empty macro as well? This covers the vast > majority of cases (e.g. like the ones in my initial patch which > started this discussion), and it doesn't preclude the possibility that > this macro becomes a number without breaking backward compatibility. > > OTOH once you define it as a number, it becomes relevant whether you > did it with #ifndef or with #undef, and so you have to commit to it. > > Just to make it clear: It's no problem to me if it's defined as a > number, but it doesn't help much either. At least from Debian POV it's > not worth making a big argument about. It could be a good idea from > FreeBSD POV, but please only do this if it's useful to FreeBSD. > I am fine with __FreeBSD_kernel being empty, please submit the patch.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:20 UTC