Hello Dirk,
sorry for the late answer.
maybe it is generally a good idea to replace the OSG-defined
symbol "darwin"
by the symbol "__APPLE__" that is defined by default on MacOS X (and
Darwin).
BTW, a similar problem exists on Windows - all Windows-specific
code is
enabled by the OSG-defined symbol "WIN32", instead of the symbol
"_WIN32"
that is defined by default (at least when using the Microsoft and
the Intel
compilers).
yeah, we had a discussion about inventing our own system-
identification
defines before, and it didn't seem necessary at the time. But given
the
fact that things apparently change more often than we expected, it
might
be a good idea to revisit that.
Here's my proposal:
add to the head of OSGConfig.h some platform/compiler detection
defines.
I'm thinking of defines like these:
OSG_OS_WINDOWS, OSG_OS_IRIX, OSG_OS_LINUX, OSG_OS_MACOSX etc.
OSG_OS (with a value of "WINDOWS", "IRIX", etc.)
OSG_OS_MAJOR_VERSION, OSG_OS_MINOR_VERSION (e.g. "2","69" for my FC3)
OSG_COMPILER_CL, OSG_COMPILER_ICC, OSG_COMPILER_GCC etc.
OSG_COMPILER (with a value of "CL", "ICC", etc.)
OSG_COMPILER_MAJOR_VERSION, OSG_COMPILER_MINOR_VERSION (e.g. "3", "42"
for FC3)
It might be worth having some combined ones for OS/compiler
combinations
like OSG_WINDOWS_ICL, OSG_LINUX_ICL etc.
Based on these OSGConfig should set feature-specific defines (which it
already does quite a lot), and the other system headers should be as
platform-independent as possible.
Comments? How do other systems handle this?
Well, the solution you propose is much better than the current
solution of defining these symbols on the command line. But I usually
prefer to keep things as simple as possible.
Your solution needs to be documented. In fact, most people don't read
documentation, so probably many people writing code for OpenSG won't
use these defines. For example, how many people actually understand
what's the difference between osg:: and OSG::?
Even worse, I fear that there is no set of defines that will handle
all special cases. For example, what about the differences between
32bit and 64bit CPUs? Or how do we differentiate between a PowerPC-
based MacOS and a Intel-based MacOS, something that is actually a
topic since monday evening ;-)
As a matter of course I understand why using an abstraction layer has
some advantages, especially concerning the fact that the __APPLE__
define is not officially documented. But:
- I don't really expect this symbol to change. All other open source
projects I've had a look at actually use __APPLE__ directly (eg. The
OpenGL Extension Wrangler Library).
- A grep on the OpenSG/Source directory shows that we just have 18
occurrences of "darwin" (and already 7 occurences of "__APPLE__" in
my own code). That's not too much to change when we are forced to
change the symbol in the future.
- On all other unix systems, the system specific symbols are used
directly (__linux, __sgi, __hpux).
So as a quick, fast and simple solution I would propose to change all
occurrences of "darwin" in the source code to "__APPLE__". I'm
willing to take care about that when there is no objection from your
side.
Best regards,
Patrick
PS: On Windows, the situation might be different, due to the
different compilers...
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
