Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-Id: <5.2.0.9.0.20030925143605.02d234f8@irispavp.igb.umontreal.ca>
X-Sender: bleau3 AT irispavp DOT igb DOT umontreal DOT ca (Unverified)
Date: Thu, 25 Sep 2003 16:46:37 -0400
To: cygwin AT cygwin DOT com
From: Andre Bleau <bleau AT igb DOT umontreal DOT ca>
Subject: Future of OpenGL package (Was: OpenGL ? Re: gcc 3.3.1: include
  problem solved)
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
X-MDRemoteIP: 10.52.50.2
X-Return-Path: bleau AT igb DOT umontreal DOT ca
X-MDaemon-Deliver-To: cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h8Q16vdL030314

Brian Ford wrote:

>These questions are mainly directed at Andre Bleau (Cygwin's OpenGL
>maintainer).
>
>I am glad that the ambiguity in gcc include search paths has been
>resolved.  However, the OpenGL includes in w32api/GL are from Mesa, and
>are thus more complete and up-to-date.

Well, I hope that Earnie Boyd, maintainer for the w32api package, will join 
this discussion.


>What are the long term plans, if any, for reconciling these two
>implementations?  It seems silly to have two copies of esstially the same
>thing.

I agree. Maybe it's time to break-up the OpenGL package into several parts:

API to native Windows OpenGL implementation, accessible through M$'s 
opengl32.dll could be in the w32api package, as it is now. The GL include 
directory could be in /usr/include/w32api exclusively, without need for 
another in /usr/include.

API to GLUT could be in a GLUT package, while the GLUT32.dll could be in a 
GLUT-runtime package.

API to GLUI and GLUIX could be in a GLUI package. There is no dll for both 
of these. They are C++ static libraries that would need to be repackaged 
each time that the C++ interface changes, as has been the case between g++ 
2.95, 3.2, and now 3.3. I hope that this interface will remain stable for a 
while now.


>Are there any plans to update Cygwin's OpenGL headers to include 1.3 or
>1.4 support?  Be it via using the w32api Mesa ones, or by other means.

Let that be clear: headers alone will not provide access to OpenGL 1.2+ 
functionnality. You will still have to program the loading of OpenGL 
extensions, if they are available from the graphic card driver. Maybe 
something like extgl (http://www.levp.de/3d/index.html) could be packaged 
for Cygwin to make that easier.


>Are there any plans to update Cygwin's glut to the current Nate Robins
>version?

Could be done; however, it is nearly 2 years old and provides no new 
functionnality. It is sad, but GLUT is dead. There is a project in 
sourceforge for a replacement: freeglut 
(http://freeglut.sourceforge.net/fg/), but is still IMO too buggy for prime 
time. However, it is actively developped and debugged, and a stable release 
is supposed to come "real soon".


>Thanks.
>
>BTW, I'm more than willing to help here.  But since your the maintainer, I
>need to know how you want to proceed.

Good to hear that. Lets discuss the issues above. Anybody interested in GL 
programming in the Cygwin environment? Please join in.





Andr� Bleau, Cygwin's OpenGL package maintainer.

Please address all questions and problem reports about Cygwin's OpenGL 
package to cygwin AT cygwin DOT com . 


--
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/