analyze pointer usage for OpenGL API for generate-XS.pl implementation

[devel-chm]

This issue is to track the progress of analyzing the OpenGL pointer usages which started with issue #7.
Per discussion on #pogl, the plan is to determine from the OpenGL specification and documentation what the various pointer arguments and return values mean for each function and to categorize all the arguments to each function as well. These non-pointer arguments often determine the details of the pointer usages:

• Number of elements
• Number of bytes
• Types of elements
• Are the arguments inputs, outputs, or both?
• Is the pointer "just a pointer" or an "offset"?
• ...

Work is underway to provide OpenGL::GLUT and OpenGL::Array as standalone modules for back compatibility. OpenGL::GLUT is almost released. OpenGL::Array should follow within the week.

The hope is that this analysis will be done enough that work to improve code generation
can begin once they are released.

[wchristian]

First step of that will be to parse badp-XS-signatures.pl into a data structure that can be edited easily.

[devel-chm]

If you could get annotated signatures for the priority list by Saturday that would be great! That is when I plan to get to improving the code generation in generate-XS.pl.

[wchristian]

#52 contains a first shot at parsing the arguments and batching them.

[devel-chm]

We're on track for the CPAN releases of OpenGL::GLUT and OpenGL::Array by tomorrow. Now that legacy OpenGL functionality is supportable, we need to finish the OpenGL::Modern bindings for "bad" routines with pointer/array arguments.

[devel-chm]

This is a list of the routines implemented in Perl OpenGL. I recommend completing them so that following the test with the required set of functions, we can be sure that the XS code generation includes these for compatibility with the OpenGL module.

pogl_compat_funs.txt

Notice that a number of the routines with '_p' suffixes appear to actually be implementations using OpenGL::Array objects rather than native perl. I think it would have been more consistent if the OGA-using routines were named '_a' or '_o' instead. However, my current plan is that the basic OpenGL::Modern implementation with perl data types and others will not have or need special suffixes. In that case, leaving the '_p' as such will provide compatibility.