OSX compile error from AGL_TARGET_OS_MAC_OSX
by John Wiederhirn · in Torque Game Engine · 12/08/2002 (4:14 am) · 7 replies
Okay, this is on 10.2.2 with Dec2002 Dev Tools update. Clean update of head. I'm getting a compile error in macCarbOGLVideo.cc (line 1024) where OpenGLDevice::initDevice() makes the call to aglConfigure. Here's the snippet...
#if defined(TORQUE_OS_MAC_OSX)
if (platState.osX) // this is redudant, since the #if checks MachO!!!
{// carbon porting guide says we MUST do this in mach-o Carbon code...
aglConfigure(AGL_TARGET_OS_MAC_OSX, GL_TRUE);
}
#endif
The compile is breaking because nowhere in the AGL,Framework headers (or anywhere else I can find) is the AGL_TARGET_OS_MAC_OSX enumeration value defined. In fact, I can't find _any_ AGL_TARGET_* values defined.
Is this a headers problem? Or did Apple remove stuff with the Dec2002 tools update which used to be in AGL.Framework? Or something else entirely?
I'll take any help I can get at this point, even just knowing that call isn't necessary and can be omitted would be fine. I just need to get going again, but removing the Dec2002 update to tools/headers is not going to go over very well around here, as its GCC3.1 handling is a LOT more stable (for us, anyway) versus the prior "beta" GCC3.1 in the July/Oct2002 dev stuff.
#if defined(TORQUE_OS_MAC_OSX)
if (platState.osX) // this is redudant, since the #if checks MachO!!!
{// carbon porting guide says we MUST do this in mach-o Carbon code...
aglConfigure(AGL_TARGET_OS_MAC_OSX, GL_TRUE);
}
#endif
The compile is breaking because nowhere in the AGL,Framework headers (or anywhere else I can find) is the AGL_TARGET_OS_MAC_OSX enumeration value defined. In fact, I can't find _any_ AGL_TARGET_* values defined.
Is this a headers problem? Or did Apple remove stuff with the Dec2002 tools update which used to be in AGL.Framework? Or something else entirely?
I'll take any help I can get at this point, even just knowing that call isn't necessary and can be omitted would be fine. I just need to get going again, but removing the Dec2002 update to tools/headers is not going to go over very well around here, as its GCC3.1 handling is a LOT more stable (for us, anyway) versus the prior "beta" GCC3.1 in the July/Oct2002 dev stuff.
#2
Bug is filed, but wasn't sure what severity to give it as the system isn't really suited for compile-time errors. Hope it makes sense.
I'd check in the fix, but since there may be issues with folks using older developer tools (they weren't very clear as to what 'deprecation' means, and whether that means it still applies to builds targetting earlier versions/revisions of Carbon, etc.). I'll leave it to the experts to figure things out.
12/08/2002 (4:53 am)
Hehe, sorry, that should have said _Geoff_ Stahl, not Greg Stahl. Don't want to bring down any AppleWrath on myself.Bug is filed, but wasn't sure what severity to give it as the system isn't really suited for compile-time errors. Hope it makes sense.
I'd check in the fix, but since there may be issues with folks using older developer tools (they weren't very clear as to what 'deprecation' means, and whether that means it still applies to builds targetting earlier versions/revisions of Carbon, etc.). I'll leave it to the experts to figure things out.
#3
I'll go find an appropriate wrapper for it.
d
12/08/2002 (8:36 am)
yeah, that's their usual 'bland' response. unfortunately, there are actually people who won't pay to upgrade to Jaguar, so can't just rip it out if it's a Jag fix to GL/Carbon compatability.I'll go find an appropriate wrapper for it.
d
#4
Specifically, there are now a bunch of files (but not all) in the 'fx' group, and all of the files in the 'net' and 'vehicles' groups, which are listed as absolute paths instead of project-relative paths.
So, unless people happen to have
/Volumes/Shared/cvsroot/
as their suffix to where the torque tree lives (I don't), the files come up as missing during builds. Seems like an easy enough fix, but I'm not quite sure how it happened to begin with, and thus will leave it to you to repair, okay?
12/08/2002 (3:56 pm)
Understood, and the fix looks fine. Unfortunately, it appears when you checked it in, you inadvertantly 'broke' a bunch of files' attributes in the torque_10_2.pbproj.Specifically, there are now a bunch of files (but not all) in the 'fx' group, and all of the files in the 'net' and 'vehicles' groups, which are listed as absolute paths instead of project-relative paths.
So, unless people happen to have
/Volumes/Shared/cvsroot/
as their suffix to where the torque tree lives (I don't), the files come up as missing during builds. Seems like an easy enough fix, but I'm not quite sure how it happened to begin with, and thus will leave it to you to repair, okay?
#5
David, or anyone else that does Mac and has write access to the CVS server should correct the project files, as I'm sure lots of people are going to stumble on this one...
12/09/2002 (3:49 pm)
Yep,saw the same kind of stuff in the latest 10.2 proj...(the pseudo missing files)David, or anyone else that does Mac and has write access to the CVS server should correct the project files, as I'm sure lots of people are going to stumble on this one...
#7
really easy to edit the PB project file, as it's just text. just did a search for cvsroot, changed each to a relative entry, changed reftype to 2 (i think), and done.
d
12/09/2002 (10:26 pm)
try the latest HEAD.really easy to edit the PB project file, as it's just text. just did a search for cvsroot, changed each to a relative entry, changed reftype to 2 (i think), and done.
d
Torque Owner John Wiederhirn
I'm presuming they mean the need to issue the aglConfigure(AGL_TARGET_OS_MAC_OSX,GLTrue) function in Mach-O Carbon pgms is deprecated, since they didn't mention a different define which should be used instead. I'll try pulling it out of the code and seeing what happens, and I'm also going to file a bug on it.
Thanks, and sorry for the false alarm (sort of).