Re: [Plib-users] Building Plib on Mac OSX (Darwin)

[Steve B. <sjb...@ai...>]

Sebastian Ude wrote:

> > 2. remove "-O6" from CXXFLAGS and CFLAGS in the Makefile ??? where did
> > this come from ???
> 
> The "-O6" stuff was removed recently in CVS.

Dunno - some attempt to get more speed by increasing the optimisation level
I guess.

Does that cause problems to someone?
 
> > 2.  changed some #include statements accordingly:
> >       from <GL/foo.h> to <OpenGL/foo.h>
> >       from <ag.h> to <AGL/agl.h>
> >       from <CodeFragments.h> in util/ul.h to
> > <CoreServices/CoreServices.h>. I also added #include <unistd.h> to
> > util/ul.h after CoreServices (for the sleep() function)
> 
> I think we should add some more #ifdefs to the code so that PLIB
> automatically includes the correct header files on Mac OS X.

Yes - definitely. Now that Mac==UNIX, we need to make better efforts
to support the beast.

> > 3. add -Dmacintosh to DEFS in the Makefile.
> 
> Hmm ... you had to do this manually ?
> 
> We have to find a way to determine whether the machine we are compiling on
> is running Mac OS (X) *without* forcing the user to tell us ...

Yes.  Looking to see if glut.h is in <GLUT/glut.h> might be one way.

I can't imagine any other company making it so difficult to write
portable code!  (OK - actually, can *easily* imagine one other).
 
> > 4. changed int vp [ 4 ] ; on line 202 of ssg.cxx to GLint vp [ 4 ] ;
> > 5. changed int ww; on line 112 of ssgLoadTexture.cxx to GLint ww;
> 
> Why exactly was this neccessary ?

Perhaps they somehow made the GL types *not* be a simple typedef or #define
of the basic types.  If that's true then writing good code is going to be
VERY painful.
 
> PLIB passes normal int / float (whatever) variables or pointers to these
> types to the OpenGL routines expecting a GL* data type all the time (just
> look at PUI), and up to now, this has not caused any trouble as far as I
> can tell.

Indeed.
 
> If it does on Mac OS X, we have to change lots of lines (okay, in this
> case, 'sed' would be our friend ...).

Not really - in many cases the SSG API says that some parameter is an 'int'
or a 'float' when really it's going to be passed into OpenGL.

I doubt that it can be true in all cases - for example, just below where
that 'int vp [ 4 ]' line is, we have:

   glMultMatrixf ( (float *) mat ) ;
                    ^^^^^^
                  Notice that this *isn't*
                  a GLfloat as MultMatrix specifies.

> > Frameworks are Darwin's way of doing libraries, they are versioned
> > bundles (directories, actually) of headers,libraries and resources...
> > to link to a framework SOMEFW, you pass '-framework SOMEFW' to cc, and
> > to include header files out of it you include <SOMEFW/header.h>.
> > Frameworks are a nice idea... but a pain in the ass for porting stuff
> > from other unix platforms...

Yes - but surely the old way must work too?

Apple clearly don't seem overly concerned about portability.  Why else would
they have moved glut.h ?
 
> Hmm ... who knows how to properly implement that stuff in our (up to now,
> pretty simple) autoconf-based build system ?

I doubt you could use autoconf.  It has things like '-L' and '-I' directives
hardwired in.

Perhaps we have to give up and treat it like we do MSVC and Borland under
Windoze where we just distribute a complete parallel build environment.

That will only work if there are reasonable numbers of Mac OSX users on
the mailing list to keep them up to date though.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net