[openbeos] Re: PPC versions
- From: "David Reid" <mail@xxxxxxxxxxxxxx>
- To: <openbeos@xxxxxxxxxxxxx>
- Date: Fri, 12 Apr 2002 09:21:49 +0100
OK, I'm going to reply here based on a lot of experience with making things
run on a lot of platforms...
Nathan - you're both right and wrong in the same breath.
Basically here's why. If we're going to do this we need to do system
detection at the start of the build and set ALL the things we need. So,
who's going to write the configure scripts?
Exactly. They are messy and take time to get right (trust me - been there,
done that). Without them we could only ever offer partial solutions.
I know - we'll all stop development and write the configure stuff so we can
build on each platform we're interested in!
Not a good thing given where we are at present.
Supporting multiple platforms is something we will eventually do. No
problem. However, it's a question of how. If we have a new kernel and it's
build system is gnu for all platforms we remove a LOT of the issues, and as
that's the goal I suggest we wait on multi platform. If people want to build
and don't have access to x86 say so and someone will arrange it :)
I've had the offer of access to a PPC box so when I have some time I'll
start looking at PPC. It's not #1 on my list of things to do though.
Additionally, adding _EXPORT at the start is INCREDIBLY limiting... Why not
have a PUBLIC_EXPORT macro and simply define it correctly for the machine?
Much more flexible and more obvious as well. Oh yeah, that would need
platform checking and detection, which brings me back to the start of my
email...
david
> > >It's not about making things easy. It's about not making things
> > > hard.
> > >The two are very different. It's the same argument as not writing
> > > all
> > >your code in x86 assembler. Writing in C/C++ isn't a good idea
> > > because
> > >it makes a PPC port easier but because it doesn't make a port *
> > > harder*.
> > >Remember the original subject of my e-mail: how not to *actively
> >
> > I don't think that the two compare. Writing in C/C++ makes coding
> > faster, more
> > bug free and easier. Putting _EXPORT in front of some (but not all)
> > of your classes
> > and/or functions makes coding slower.
>
> By how much? Oh yes, hardly anything. If you forget occasionally, some
> minion like me will see the linker error and go back and add it.
>
> > >prevent* a ppc port. Not only that, _EXPORT makes code more
> > > readable.
> >
> > There is no evidence to support this at all. At the very most, this
> > would be
> > an issue of opinion.
>
> See below.
>
> > >It seperates the external API from the internal support environment
> > > and
> > >marks what can and cannot be changed without breaking compatibility.
> > >All too often in the OBOS code I've seen, this distinction has
> > > become
> > >blurred.
> >
> > We have a wonderful guide to this - the BeBook.
>
> Yeah, right. Look at the network code (I've had the most experience
> here recently). There are something like 60 (maybe more) exported
> functions. Maybe five are in the Be Book. The Be Book is not
> everything, especially if you want to share internal APIs (like add-on
> APIs) between components of your kit, add a class, a couple functions
> here or there.
>
> > >> I agree, here. But there are a very small number of people with
> > > > PPCs
> > >> that can help.
> > >> And the trouble of adding *stuff* to the code to support a 5 year
> > > > old
> > >> compiler/proprietary
> > >> file format combination just doesn't seem worthwhile to me.
> > >
> > >It's not to support PEF/mwcc. It's too avoid writing code that uses
> > > *
> > >GCC-only extensions*. The world out there is bigger than x86/gcc,
> > > and
> > >we should code with that in mind.
> >
> > Excuse me? Maybe I missed something. PPC/ELF doesn't require _EXPORT.
> > Secondly, not using _EXPORT is ***NOT*** a GCC-only extension.
> > Solaris Forte, as a counterpoint, doesn't require them.
>
> Does Solaris use ELF? I'll bet it does.
>
> > Windows has them, Macs have them, but that is not sufficient to make
> > it a standard.
> > In fact, anything that starts with an _[A-Z] is reserved for
> > implementation specific
> > "stuff". (Draft Standard 2.10.2). So, I guess I can agree with you -
> > the world IS bigger than
> > any particular compiler and we should avoid compiler specific issues.
> > So, no, _EXPORT is *STILL* not required. Or even encouraged.
>
> I'm not quite sure what to say to this. How about "de facto standard"?
> BeOS has them too. They are eminently ueful, and improve understanding
> of code by demarcating public entrypoints and private support code.
> -Nathan
>
> --
> Fortune Cookie Says:
>
> "I had to hit him -- he was starting to make sense."
>
>
Other related posts:
