This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Future of OpenGL package (Earnie, please read this)

On Tue, 30 Sep 2003, Andre Bleau wrote:

> Igor Pechtchanski wrote:
> >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.

Well, I was actually thinking of the GL library having a wrapper for each
function that did the check and either called the real function or failed.
The UNIX code won't change at all, and the wrappers in your library will
initially look like Option A above.  Then whoever needs the functionality
can send you implementations of "myOwn2000LinesOfCodeFunction"s, which you
can add as you see fit.

> [snip]
> > > - 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.

Sure...  You could coordinate the recompile with a major release, and then
name the DLLs after the older version that each represents (e.g., see
      |\      _,,,---,,_
ZZZzz /,`.-'`'    -.  ;-;;,_
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]