My programs, no matter how basic (even just , seem to compile extremely slowly, even on my new G5. The same file complies in about 1 second on a similar linux machine. If you have any ideas or questions, post here or mail me, cadsuane at mac dot com

My makefile is:

LIBDIR = -L"/System/Library/Frameworks/GLUT.framework" -L"/System/Library/Frameworks/OpenGL.framework/Libraries"
FRAMEWORK = -framework GLUT -framework OpenGL
COMPILERFLAGS = -Wall
CC = g++
CFLAGS = $(COMPILERFLAGS)
LIBRARIES = -lGL -lGLU -lm -lobjc -lstdc++
All: file

file:
-(CC) (FRAMEWORK) (CFLAGS) -o @ (LIBDIR) (LIBRARIES) $@.c

if you use xcode you can do multiple compiles concurently to each processor if you have a dual box. its under xcode preferences. not sure if this answers your question but it might help.

GCC is slower on MacOSX than on Linux/Intel, but the real killer for Mac compile performance is ld. If you use Xcode, you can use ZeroLink for development builds, which cuts ld time down to virtually nothing.

Hi, using both of your processors can be done from within makefiles too.
the option is “-j2” for a two procc. machine. It might even be better to write a -j4. (experiment)

Another thing:
It is not needed to add the paths to frameworks in your LIBDIR.
the -framework settings do this for you.

Also: there is no reason to manually add -lstdc++.
this is done for when you are using the g++ compiler.

And as someone said erlier, gcc for ppc is not as fast as for x86 yet. But apple has done great strides in this compartment (they actually has the largest developement team on gcc Ive heard), and I think we have great things to come!.

If you want to keep your makefile platform independent, use “uname” (look at man page in terminal)

a “uname” call in the termnal yields “Darwin” on os x and “Linux” on linux and “IRIX64” on sgi.

I usually define my uname result into my app.

see example below.

<inMakefile>
PLATFORM_OSTYPE = $(shell uname)

oki silly stuff here… but…

ifeq ($(PLATFORM_OSTYPE) , Darwin)
CPP := c++
STATIC_CCFLAGS := -D$(PLATFORM_OSTYPE) -Wall

#…
#…
endif

#and whatever comes

</inMakefile>

the nice thing with defining the uname result during the compilation is that you can use this settings for
#ifdef checks in your code.

ex)
#ifdef Darwin
do Darwin specific stuff here…
#endif

Dont polute your code though!

I typically hide the usage:

like in my DataTypes.h

  
#ifndef __DATA_TYPE_H__
#define __DATA_TYPE_H__

#ifdef Darwin
#include "DarwinDataTypes.h"
#endif

#ifdef Linux
#include "LinuxDataTypes.h"
#endif

// etc..

#endif  /* __DATA_TYPE_H__ */

oki hope this helpes. (got a bit carried away

OK, thanks for the info about XCode, it does indeed make stuff compile faster.

One other thing that I have noticed is that when taking code directly from linux (since that is where they test it for our assignments) to my mac, it seems that coordinates are different. For example, an animation of a cylinder falling over and rolling was hard coded to show the cylinder being about 1/4 the height of the window on linux, but when I compiled and ran it on mac, the following was different:

-the cylinder was about 2/3 the height of the window
-the point of view (glLookAt) was much closer to the center
-there appeared to be a clipping plane around -1 on the z axis, causing the back of the cylinder to disappear when it was falling over, and to become visible again as it rolled away. I played with clip planes to try and understand it, but to no avail.

that is highly unlikely!

I’d suggest that you’ve probably got some code being run on one platform and not the other, or that you’re triggering an error state where certain calls are being accepted on one platform and rejected on the other.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.