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/