Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 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/