On Fri, 26 Sep 2003, Andre Bleau wrote:
> ... > Even, with 1.4 headers, you would sill need to jump through hoops to use > 1.4 functionality. You will still need to load the functions dynamicaly > before using them. You wouldn't be able to simply call the functions as > when developing for UNIX.
Andr�,
Cygwin DLL uses the autoload functionality for some of the required functions, so that they can simply be called after a test (i.e., something like
if (hasSomeFunction()) callSomeFunction();
Perhaps this could be employed in the OpenGL library layer as well... I don't know enough off-hand about the autoloading process, but there is a fairly detailed description in winsup/cygwin/how-autoload-works.txt in the Cygwin sources. Might be worth investigating...
Well, that's exactly what packages like extgl provide: an easier way to test if some functionality is available, and if it is, to load it and use it.
I was thinking of including extgl in the next major release of the OpenGL package.
However, porting UNIX program that uses GL 1.2+ functions would still be a pain, although a somewhat lower pain. Say you have a UNIX program with a line like this:
glNewFunctionThatDrawsACompleteKitchenIncludingTheSink(GL_KITCHEN_COLOR_PATTERN);
The Cygwin version would be, if we would use something like extgl:
Option A:
if (hasNewFunctionThatDrawsACompleteKitchenIncludingTheSink)
glNewFunctionThatDrawsACompleteKitchenIncludingTheSink(GL_KITCHEN_COLOR_PATTERN);
else {
fprintf(stderr, "Sorry, can't draw your kitchen. Please update your GL drivers and come again.\n");
exit(1);
}
or, Option B: if (hasNewFunctionThatDrawsACompleteKitchenIncludingTheSink) glNewFunctionThatDrawsACompleteKitchenIncludingTheSink(GL_KITCHEN_COLOR_PATTERN); else myOwn2000LinesOfCodeFunction(GL_KITCHEN_COLOR_PATTERN);
There are dozens of GL 1.2+ functions now. If you select Option A, rewriting some program to use them conditionally can be a major task. As for Option B, it is a task of Herculean proportions.
> [snip] > > I think we waited long enough for freeglut and some update of GLUT and GLUI > is overdue. > > So, I propose to make a quick update of the OpenGL package ASAP, while we > wait for freeglut. To quick update would: > > - Remove /usr/include/GL and rely on /usr/include/w32api/GL from the w32api > package, that would be set as requesite > - Add glut.h to /usr/include/w32api/GL
So you need to coordinate with Earnie on this (as the subject says).
Yup.
> - Update the GLUT dll to Nate Robin's 3.7.6 > - Have GLUI and GLUIX libs compiled for gcc 3.3
You will probably also need to release the old libraries as compatibility packages for those who still use the pre-gcc-3.3 OpenGL binaries.
So, you suggest that I provide:
libglui.a and libgluix.a for the last version of gcclibglui-gcc3_2.a and libgluix-gcc3_2.a for gcc 3.2
libglui-gcc2_95.a and libgluix-gcc2_95.a for gcc 2.95
???
None would be bigger than 500k, so the package would still be manageable.
> - Move the doc to /usr/share/doc
This would be useful.
Just my 2c. Igor
After the long silence that followed my last posting to cygwin-apps about these issues, it's good to receive some feedback. Thanks Igor and Brian.
Andr� Bleau, Cygwin's OpenGL package maintainer.
Please address all questions and problem reports about Cygwin's OpenGL package to [EMAIL PROTECTED] .
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
