2011/7/5 Alexander Kabaev <firstname.lastname@example.org>:
> Only because there was no GNU/kFreeBSD before and people got lazy. Using
> __FreeBSD__ to identify userland can be considered just as wrong
> practice as using __linux__ for the same purpose, yet several years
> have been spent fixing this on Linux and quick hack is somehow
> appropriate for FreeBSD. Why do you keep arguing that intended use of
> __FreeBSD__ is any different than one of __linux__? It is not and both
> should be fixed when misused.
I think there's an underlying discussion about naming convention here.
You said you wanted to leave it out of the list, but it is central to
your argument. I try to keep a purely pragmatic approach, but when
you say "using this name may work well, but it is wrong", then we have
to argue about what is right and what is wrong, and we can't have a
pragmatic discussion anymore. It has become http://tinyurl.com/qysbk
>> I'm asking FreeBSD project to make life easier for a derivative that
>> is, one way or another, part of its ecosystem, at no cost other than
>> the time spent discussing the proposal.
> Not true, the change does break backward compatibility with older
> software if the new macro were to be used as you propose, to enable the
> code that is specific to FreeBSD kernel.
It is a timing issue. I don't propose that the macro is used _before_
it has become appropiate to use it. A several year period would be
necessary for 3rd party software.