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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
