[openbeos] Re: PPC versions
- From: "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 09 Apr 2002 22:50:36 EDT (-0400)
> OK. This is starting to not go anywhere.
Indeed, which is massively unfortunate.
> _EXPORT is a compiler specific thing.
Not really. The *necessity* of _EXPORT is format dependant, but it *
works* everywhere.
> It is 7 characters.
> It is not standard C++.
> It is not earthshakingly difficult to type.
> It is (a little bit) more work.
> ELF doesn't require _EXPORT.
> It is useful if you want to port to a non-ELF system.
> It can be used to document what is meant to be external and what is
> not.
> It is used by a number of formats.
> None of them matter to us for the forseeable future, except PEF.
Yes.
> ELF is implemented everywhere, except Windows and Mac (anyone know
> what OS X uses?)
And together that's 98% of the computers on the planet. All life is
mammalian, except the 98% that's not.
OS X uses GCC and Mach-O. I do not know much about its shared library
system except that, like old-style MacOS, it seems really, really
strange.
> Since GCC is the one free compiler that we all have, and GCC makes
> ELF, focusing on ELF makes sense.
GCC makes other things, too. It makes ELF, COFF, X-COFF, Mach-O, a.out,
even PEF.
> Many/most of the OBOS kits will not be usable on R5's kernel for very
> much longer, since we are quickly coming to the few points of impact
where there are kernel issues.
> This is not worth arguing over.
>
> Really. This has wasted more time than any of us can afford. PEF,
> COFF, PE, etc are not realistic targets for OBOS, either now or in the
forseeable future. I am sorry.
OK. So there will be no OBOS patches for PPC, no beta testing to ensure
endianness compatibility, nothing. Until the NewOS kernel is ported,
all cross-platform compatibility issues will be avoided like the
plague. All vision is limited to x86 and ELF. Right. I warn you,
though, that things like endian independence *will* disappear if not
tested, and you will face a *massive* reality shock come R1 time, and
may never decide to leave x86 at all. Which, needless to say, is both
blinkered and utterly idiotic.
Let us consider what causes delays in coding. Is it (1) being
required to actual invent algorithms and write the code, or (2) being
required to do maintenance chores like adding function prototypes?
Adding _EXPORT declarations, of course, falls in the second category,
and requries almost no time. Only one is required per class or global
function. That's not a lot of extra work, and if everyone did it, the
cumulative effect on the OBOS R1 release date *might* cause it to ship
up to 20 minutes late. Gosh. That's pretty unacceptable, huh? I'll bet
that's less time than this entire discussion took. And the result? A
PowerPC port that "just works".
And, there, ladies and gentleman, is the end of any coding that I
will be able to do for the OpenBeOS project "either now or in the
foreseeable future" (other than the NewOS kernel, which needs a lot of
work as it will not compile except with GCC, nor does it even work with
the GCC included in OS X) since I am one of those hapless souls (and
there are hundreds of us who use BeOS, btw), who happen to own all
PowerPC hardware.
-Nathan
--
Fortune Cookie Says:
The hearing ear is always found close to the speaking tongue, a custom
whereof the memory of man runneth not howsomever to the contrary,
nohow.
Other related posts:
