[PATCH] fake pre-processor macros when building on non-FreeBSD system

[Robert Millan]

2011/7/12 Alexander Kabaev <kabaev at gmail.com>:
> The fact that Linux compiler with manually undefined and re-defined
> platform macros can compile is a coincidence and is not guaranteed to
> work and certainly is not a goal of FreeBSD project so this can be
> broken at any moment.

There must be some missunderstanding, I never asked the FreeBSD
project to garantee this works, or that it won't break in the future.
I'm not holding anyone responsible in case it breaks, or anything
similar to that.

Once it works, however, it is not a coincidence: We've been working to
archieve this (most of my other patches sent to this list go in this
direction).

That aside, it seems there's some interest in FreeBSD community about
building the kernel on GNU/Linux.  In particular, MIPS porters have it
in their TODO list:
http://wiki.freebsd.org/FreeBSD/mips/todo

> putting hacks into
> FreeBSD sources to legitimize the practice is not the move I would
> support as well. Traditionally, IMHO.

I try to take a neutral stance and merely follow on what the source
tree expects.  If the source tree does things like:

#ifdef __FreeBSD__
// code that expects to be built as part of the FreeBSD kernel tree
// (this chunk of code is invariably what we want, no matter the
compiler we're using)
#endif

#ifdef __linux__
// code that expects to be built as part of the Linux tree
// (this chunk of code depends on out-of-tree headers and will never
build, no matter the compiler we're using)
#endif

I naively read this as "when building kernel code, we assume these
macros refer to *what* we're building rather than to what are we
building it *for*".

My naive mind can't tell if this assumption is correct or not, it
merely tries to adapt to existing practice. If the assumption is not
correct, then I would propose a different kind of solution to the
problem.

So before we proceed, could you clarify whether the assumption is
correct or not?

-- 
Robert Millan