From: Sven P. <Sve...@ae...> - 2009-06-25 22:08:48
|
Am Donnerstag, 25. Juni 2009 22:40:03 schrieb Fay, John F Dr CTR USAF AFMC 46 SK: > I just tried running a "freeglut" demo and found that it would > not build with the current "freeglut" library. Two functions were > missing: "__glutCreateMenuWithExit" and "__glutInitWithExit". I have > found both of these functions inside a "#ifdef" block checking for the > definition of "_WIN32". It transpires that that particular symbol is > not defined on my Windows machine with my MSVC 6 compiler. I really doubt that _WIN32 is not defined there, because other parts of freeglut need it on Windows, too, and I have never heard that this is not defined on Windows. > Several questions come to mind: > * How do the demos behave on Linux systems? If the demo uses __glutFoo directly, the demo is buggy: These are internal functions, and they are clearly marked as such in the freeglut_std.h header. > * What are we doing with "_WIN32" checks rather than > "TARGET_HOST_WINDOWS" checks? Because the whole ATEXIT_HACK stuff is more or less cloned from the GLUT shipped with Mesa. I explicitly do not want to deviate from them to keep binary compatibility and source compatibility as much as possible. > * Why do we have interface functions that begin with a pair of > underscores? A note in the SVN logs says that this makes it binary > compatible with some GLUT 3.7 DLLs that are "out in the wild." A "grep" > in my GLUT 3.7 source files reveals no such functions. You have to look in Mesa's GLUT, not the ancient GLUT sources floating on the web. They are definitely needed to make us binary compatible with Nate's DLL, just try his precompiled tutorials. > This last point deserves further discussion. Mark Kilgard was > adamant that NOBODY was allowed to modify the GLUT source code and > redistribute it. A little research on the web reveals a "GLUT 3.7.6" by > Nate Robins, who ported the original GLUT to Windows. I realize that we > are not modifying GLUT source code, so we aren't in any legal trouble on > this score. (There may be some trouble about using the same internal > variable names, though.) But is this a road that we want to go down? > How legal is GLUT 3.7.6? Are we breaking binary compatibility with > earlier, legal versions of GLUT by including this? Nope. The other way round: If we do *not* provide these entries, we are not binary compatible with Nate's de facto standard GLUT DLLs. To be honest: I don't care about the legal status that much: Nate's DLLs and the GLUT shipped with Mesa are out in their current form for years and I even heard rumours that they had any trouble with Mark. The point is: The official GLUT source API is not changed at all through the ATEXIT_HACK, the __glutFoo entries are purely internal. Due to C's poor (i.e. absent) handling of scoping, these are visible in the DLLs. This is probably not against Mark's intention, anyway, because it is not an additional feature, but only a hack around Window's silly C runtime. > The latest bit of momentum for a 2.6.0 release seems to have > sputtered and spent itself, and so we may have just dodged a bullet > here. We need Steve Baker's input here before we go any further. The question is: Is Steve really still acting as the project admin? The SF page lists fayjf, puggles, and sjbaker as admins, but only you are currently doing anything. This situation is highly demotivating and I propose that *you* should make the 2.6.0 release now and probably take over the project lead "hat" from Steve, as he obviously has no interest in freeglut anymore. Changing one's focus is OK and I fully understand that, but then roles should be passed to people which are still more involved. Cheers, S. |