Bug #64700 for OpenGL: installation on ActivePerl does not work properly due to faulty Cygwin recognition (patch included)

Tue Jan 11 12:46:26 2011 MITHALDU [...] cpan.org - Ticket created

Subject:

installation on ActivePerl does not work properly due to faulty Cygwin recognition (patch included)

Currently in your code you try to recognize whether we're running Cygwin by trying to run uname. Sadly this has the side effect of also simple checking whether Cygwin is *installed*. This means when trying to install on ActivePerl with Cygwin also installed the Makefile.PL gets into an improperly defined state and ignores the %Config settings for which make to use. Since you do not have a contribution policy defined in your documentation (please add one), I've chosen to make the patch available to you in this form: I've uploaded a repo with the history of this module to github and committed my changes to this branch: https://github.com/wchristian/pogl/ commits/wchristian You can pull from my repo via this url: git://github.com/wchristian/ pogl.git As an additional note: I cannot help much with the C side of things, but i'd happily contribute by working my way through the perl files in the distribution, refactoring, cleaning and tightening code whereever possible in order to move towards a more modern Perl. If you have interest in me doing this, please let me know how you would prefer to receive my contributions. (My preferred method, excluding direct access, would simply be to have me send pull requests to your fork on github.)

Tue Jan 11 13:40:51 2011 chm [...] cpan.org - Correspondence added

On Tue Jan 11 12:46:26 2011, MITHALDU wrote: Show quoted text

> > Currently in your code you try to recognize whether we're running > Cygwin by trying to run uname. Sadly this has the side effect of also > simple checking whether Cygwin is *installed*.

Right. The current OpenGL configuration is build time only and pretty crufty as well. I have plans to refactor the module for portability and runtime OpenGL support. I hope to get to that this Spring. Show quoted text

> I've uploaded a repo with the history of this module to github and > committed my changes to this branch: > https://github.com/wchristian/pogl/commits/wchristian > > You can pull from my repo via this url: > git://github.com/wchristian/pogl.git

The git source tree for OpenGL is currently hosted in the Perl Data Language project on sf.net. Read-only access to that repo is: git://pdl.git.sourceforge.net/gitroot/pdl/pogl Show quoted text

> As an additional note: I cannot help much with the > C side of things, but i'd happily contribute by working > my way through the perl files in the distribution, > refactoring, cleaning and tightening code where ever > possible in order to move towards a more modern Perl. > > If you have interest in me doing this, please let me > know how you would prefer to receive my contributions. > (My preferred method, excluding direct access, would > simply be to have me send pull requests to your > fork on github.)

One thing that would help would be simply to add to the TODO list with things you come up with and how or where they might be implemented. The biggest challenge I see is that the basic OpenGL bindings are very crude. I've cleaned up the build process with the existing code so it now builds on most perl platforms. There is still work to do but *real* progress needs to be in restructuring the build and binding process. Here is an outline of the current plans: (1) Switch from ExtUtils::MakeMaker to Module::Build to take problems with shell and make program versions out of the configure process for portability. Module::Build configuration only needs perl and C. (2) Move OpenGL library detection from the OpenGL configure/build process into an Alien module like Alien::OpenGL. (3) Switch from rolling our own perl<->OpenGL binding to one based on the GLEW library in something like Alien::OpenGL::GLEW. Using GLEW means that we automatically can support bindings for OpenGL versions up to 4.2 (currently), the bindings are the same for all perl platforms, using GLEW as the base means we can autogenerate the XS from the GLEW source which should make things much more maintainable. (4) Add "friendly" perl-ish bindings for the many OpenGL API calls like glColorXX so a single glColor() would transparently call the appropriate glColorXX() at the C level. (5) Add bindings to GLUI to the OpenGL module to allow more sophisticated GUIs to be developed using OpenGL+GLUT+GLUI as a *very* portable option to perl/Tk and others. There are a number of GUI widget sets out there for perl but the last time I checked they all did not work on one perl platform or another (e.g., win32, mac os x, linux, solaris, *BDS,...). A simple GUI environment based on OpenGL could provide a basic, completely portable GUI. I've figured out how all of this can be done but have been busy working on some Perl Data Language releases (trying to get it building out-of-the-box on win32 platforms). I would welcome your thoughts on all this and would be happy to add your patch if you could provide it against the official git above. Cheers, Chris

Tue Jan 11 13:40:51 2011 The RT System itself - Status changed from 'new' to 'open'

Tue Jan 11 13:51:14 2011 MITHALDU [...] cpan.org - Correspondence added

On Tue Jan 11 13:40:51 2011, CHM wrote: Show quoted text

> I would welcome your thoughts on all this > and would be happy to add your patch if you > could provide it against the official git > above.

Gonna read the rest of your mail in a bit, but wanted to answer this first so i don't keep you waiting. My github copy is a direct fork of yours and has all your history, so you can just do this: git remote add wchristian git://github.com/wchristian/pogl.git git fetch --all git merge wchristian/wchristian ( This kinda stuff is what git is there for. ;) )

Tue Jan 11 14:19:57 2011 MITHALDU [...] cpan.org - Correspondence added

On Tue Jan 11 13:40:51 2011, CHM wrote: Show quoted text

> Right. The current OpenGL configuration > is build time only and pretty crufty as > well. I have plans to refactor the module > for portability and runtime OpenGL support. > I hope to get to that this Spring.

That's what i meant when i said refactoring. The current Makefile.PL is really, really ugly and i can't imagine what kind of weird behaviors it has hidden; so i would first like to completely refactor it so it actually gets somewhat readable, then do the same to whatever actual Perl floats around in this distribution. Show quoted text

> The git source tree for OpenGL is currently > hosted in the Perl Data Language project on > sf.net. Read-only access to that repo is: > > git://pdl.git.sourceforge.net/gitroot/pdl/pogl

As i mentioned in my previous email, that's where i forked my repo from. :) I find patches to be cumbersome to work with, since windows doesn't exactly come with tools to handle them gracefully. However since git allows you to add any remote url you want as an additional source for the repo to pull branches from, i can simply have mine and yours in my repo and pull down from yours to update mine and conversely you can pull data from mine as if it was a simple branch in your repo. (Going completely via github would have the added benefit that you could review pull requests in the browser in a very convenient view.) Show quoted text

> One thing that would help would be simply to add to > the TODO list with things you come up with and how > or where they might be implemented.

There's one thing i might have to check later, which relates to a now- abandoned project of mine in which i added support for a few functions regarding occlusion culling that were missing in earlier versions of this module. Right now however i'm not actually doing anything with OpenGL and am only planning to play around with it for the purposes of demo making. If anything comes up i'll be sure to pipe up. :) Show quoted text

> (4) Add "friendly" perl-ish bindings for the > many OpenGL API calls like glColorXX so > a single glColor() would transparently > call the appropriate glColorXX() at the > C level.

That is a neat idea. I could make an OpenGL::Helper module in basic Perl that combines such calls in order to hash out the API, and someone with the needed C chops (you?) could then convert that to XS once they're happy with it. Show quoted text

> [ other things ]

I'm afraid that on the other things i cannot provide much useful input. I've never actually looked at the differences between ExtUtils::MakeMaker (though i did provide windows patches for it) and Module::Build, nor am i familiar with build exercises in particular. In the same vein, i have absolutely zero experience with all the libraries you mentioned (i am in fact still very much a beginner in OpenGL) or C, so i wouldn't know what binding them in entails. The main motivation for me really is that i'm pretty good with Perl, wanted to see if i can do something demoish with this, found out it wouldn't install, fixed that and in the process saw lots of disgusting things in Makefile.PL that i'd like to clean up. :) Additionally i'm very much a windows developer and have multiple machines with multiple perl configurations, and thus would like to offer my experience with Windows and Perl in order to help improve this module in regards to compatibility and quality.

Tue Jan 11 14:40:39 2011 chm [...] cpan.org - Correspondence added

On Tue Jan 11 14:19:57 2011, MITHALDU wrote: Show quoted text

> > The git source tree for OpenGL is currently > > hosted in the Perl Data Language project on > > sf.net. Read-only access to that repo is: > > > > git://pdl.git.sourceforge.net/gitroot/pdl/pogl

> > As i mentioned in my previous email, that's > here i forked my repo from. :)

Ok, it wasn't clear in the original post. Show quoted text

> > One thing that would help would be simply to add to > > the TODO list with things you come up with and how > > or where they might be implemented.

> > There's one thing i might have to check > later, which relates to a now-abandoned > project of mine in which i added support > for a few functions regarding occlusion > culling that were missing in earlier > versions of this module.

I expect the move to GLEW will immediately address the availability of any missing functionality. It would be nice to have some tests in the test suite that check more than just whether the module will load... Show quoted text

> Right now however i'm not actually doing > anything with OpenGL and am only planning > to play around with it for the purposes of > demo making. If anything comes up i'll be > sure to pipe up. :)

Sounds good. Show quoted text

> > (4) Add "friendly" perl-ish bindings for the > > many OpenGL API calls like glColorXX so > > a single glColor() would transparently > > call the appropriate glColorXX() at the > > C level.

Show quoted text

> That is a neat idea. I could make an OpenGL::Helper > module in basic Perl that combines such calls in order > to hash out the API, and someone with the needed C > chops (you?) could then convert that to XS once > they're happy with it.

Take a look at OpenGL::Simple which has done a bit more work in making the binding more perl-ish. Show quoted text

> The main motivation for me really is that i'm > pretty good with Perl, wanted to see if i can > do something demoish with this, found out it > wouldn't install, fixed that and in the process > saw lots of disgusting things in Makefile.PL > that i'd like to clean up. :)

I'm afraid that cleaning up the current Makefile.PL might be a waste of time given that the basic process of detecting and generating the bindings themselves is so poor. Show quoted text

> Additionally i'm very much a windows developer > and have multiple machines with multiple perl > configurations, and thus would like to offer > my experience with Windows and Perl in order > to help improve this module in regards to > compatibility and quality.

Testing new releases (do you submit CPAN Testers reports?) is a huge help---especially for multiple win32 environments. The current build/Makefile.PL could stand some fixes for specific bugs but more than that should wait until the bindings themselves are refactored to use GLEW and Alien::OpenGL. Definitely submit any problems you find and/or fix as I'd like this code base as robust as possible (given its flaws) until the new approach can come on line. In light of this discussion, I think I'll stand up an official Perl OpenGL project at some git host site so that these discussions and thoughts can continue in an open framework. --Chris

Tue Jan 11 15:04:45 2011 walde.christian [...] googlemail.com - Correspondence added

Subject:	Re: [rt.cpan.org #64700] installation on ActivePerl does not work properly due to faulty Cygwin recognition (patch included)
Date:	Tue, 11 Jan 2011 21:04:29 +0100
To:	bug-OpenGL [...] rt.cpan.org
From:	"Christian Walde" <walde.christian [...] googlemail.com>

On Tue, 11 Jan 2011 20:40:40 +0100, Chris Marshall via RT <bug-OpenGL@rt.cpan.org> wrote: Show quoted text

> Ok, it wasn't clear in the original post.

Oh, sorry, i could've said that more directly, yes. Show quoted text

> I expect the move to GLEW will immediately address > the availability of any missing functionality. It > would be nice to have some tests in the test suite > that check more than just whether the module will > load...

Thinking loud here: Doesn't OpenGL have abilities to dump the current image buffer? If so one could possibly put together a set of reference renderings that the test scripts could then generate and compare against? On the other hand: These are only bindings to another library. I'm not too sure whether it makes sense to test that that library works, vs. just making sure that the bindings don't explode when called. Show quoted text

> Take a look at OpenGL::Simple which has done a bit > more work in making the binding more perl-ish.

Will do. Show quoted text

> I'm afraid that cleaning up the current Makefile.PL > might be a waste of time given that the basic > process of detecting and generating the bindings > themselves is so poor.

I understand, i'll keep further fixes on that to actual problems i find then. Show quoted text

> Testing new releases (do you submit CPAN Testers > reports?) is a huge help---especially for multiple > win32 environments.

I have a 5.10.1 smoker running on windows 7 on a remote machine. (Though at this point it's still trying to catch up with what's already on CPAN.) Additionally everything i install on my work machine is reported as well. I'm planning to play around with perlbrew and get multiple smokers for different perl versions running on my win7 machine when it's caught up. Show quoted text

> The current build/Makefile.PL > could stand some fixes for specific bugs but more

Do you know of any specific bugs at this point or is that just a generic "if anything comes up"? Show quoted text

> Definitely submit any problems you find and/or > fix as I'd like this code base as robust as > possible (given its flaws) until the new > approach can come on line. In light of this > discussion, I think I'll stand up an official > Perl OpenGL project at some git host site so > that these discussions and thoughts can > continue in an open framework.

Will do and i really welcome that idea. Another suggestion would be to submit new releases to perl.reddit.com (once they have lucid change logs and once there's a "contribution" manual section) to get some more public visibility on the fact that work is still happening. :) -- With regards, Christian Walde

Tue Jan 11 17:38:05 2011 chm [...] cpan.org - Correspondence added

On Tue Jan 11 15:04:45 2011, walde.christian@googlemail.com wrote: Show quoted text

> > I expect the move to GLEW will immediately address > > the availability of any missing functionality. It > > would be nice to have some tests in the test suite > > that check more than just whether the module will > > load...

> > Thinking loud here: Doesn't OpenGL have abilities to dump the current > image buffer? If so one could possibly put together a set of > reference renderings that the test scripts could then generate and > compare against? On the other hand: These are only bindings to > another library. I'm not too sure whether it makes sense to test > that that library works, vs. just making sure that the bindings > don't explode when called.

OpenGL is specified so that you can reproduce the output so tests like this should be possible. Ideally, the tests could verify the correct operation of the OpenGL API via the perl binding. In practice, I would just like enough to verify not only that things compile but also that they run. Show quoted text

> > The current build/Makefile.PL > > could stand some fixes for specific bugs but more

> > Do you know of any specific bugs at this point or is that just a > generic "if anything comes up"?

Nope, just generic I want the current code to work correctly if possible. Nicely and elegantly and comprehensively come later... Show quoted text

> > Definitely submit any problems you find and/or > > fix as I'd like this code base as robust as > > possible (given its flaws) until the new > > approach can come on line. In light of this > > discussion, I think I'll stand up an official > > Perl OpenGL project at some git host site so > > that these discussions and thoughts can > > continue in an open framework.

> > Will do and i really welcome that idea. Another suggestion would be to > submit new releases to perl.reddit.com (once they have lucid change > logs and once there's a "contribution" manual section) to get some > more public visibility on the fact that work is still happening. :)

I'll take a look at perl.reddit.com (never heard of it). My biggest obstacle with perl modules is when they have dependencies built around unix or posix. Since windows doesn't have good support there and doesn't have a package distribution framework, the most difficult part is building the external libraries for windows *before* you can even deal with the perl issues. PDL, in particular, uses many libraries to provide additional graphics and computation which are not readily available on win32/x86/x86_64 systems. --Chris

Mon Feb 21 12:24:24 2011 chm [...] cpan.org - Correspondence added

On Tue Jan 11 13:51:14 2011, MITHALDU wrote: Show quoted text

> On Tue Jan 11 13:40:51 2011, CHM wrote: >

> > I would welcome your thoughts on all this > > and would be happy to add your patch if you > > could provide it against the official git > > above.

An update: I was able to checkout your branch from the information below but when I took a look at the diff between the proposed and original Makefile.PL, there were many lines of changes. They appear to be the result of reformatting the Makefile.PL but it will be a while before I have the time to work through the changes to verify before merging. If you had a way that I could apply the same reformatting to my Makefile.PL copy (perltidy and settings?) then the process would go much faster. Thanks, Chris Show quoted text

> Gonna read the rest of your mail in a bit, but wanted to answer this > first so i don't keep you waiting. My github copy is a direct fork of > yours and has all your history, so you can just do this: > > git remote add wchristian git://github.com/wchristian/pogl.git > git fetch --all > git merge wchristian/wchristian > > ( This kinda stuff is what git is there for. ;) )

Fri May 20 14:15:50 2011 chm [...] cpan.org - Severity Important changed to Normal

Fri May 20 14:15:50 2011 chm [...] cpan.org - Correspondence added

Marking this ticket as Stalled as the original requestor
has not replied with a short version of the fix for cygwin
and asperl detection/conflict.

NOTE: The migration of the Perl OpenGL to its own
repository is underway. Announcements to come.

Fri May 20 14:15:51 2011 chm [...] cpan.org - Status changed from 'open' to 'stalled'

Tue Jul 12 13:50:30 2011 chm [...] cpan.org - Correspondence added

The specific problem has been resolved with the latest POGL
CPAN Developers release: CHM/OpenGL-0.64_003.tar.gz.
Any additional problem reports this ticket or new bugs should
be reported as a new ticket in the Perl OpenGL project bug
tracker on sf.net:

https://sourceforge.net/tracker/?group_id=562483&atid=2281758

Thanks,
Chris

Tue Jul 12 13:50:31 2011 The RT System itself - Status changed from 'stalled' to 'open'

Tue Jul 12 13:50:31 2011 chm [...] cpan.org - Status changed from 'open' to 'resolved'

Bug #64700 for OpenGL: installation on ActivePerl does not work properly due to faulty Cygwin recognition (patch included)

Preferred bug tracker