On Mon, 2008-04-28 at 08:44 -0700, Geoffrey Broadwell wrote:
I'm not wedded to splitting them up as much as I did. In fact, I'd be
fine with core.in, opengl.in, and misc.in. Better for you?
chromatic confirmed on IRC that this was his preference, saying also
that this arrangement solves
On Tuesday 06 May 2008 19:26:46 Geoffrey Broadwell wrote:
On Mon, 2008-04-28 at 08:44 -0700, Geoffrey Broadwell wrote:
I'm not wedded to splitting them up as much as I did. In fact, I'd be
fine with core.in, opengl.in, and misc.in. Better for you?
chromatic confirmed on IRC that this
# New Ticket Created by Geoffrey Broadwell
# Please include the string: [perl #53430]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53430
Currently, src/call_list.txt is a static file; any time new NCI
signatures
On Sunday 27 April 2008 17:04:10 Geoffrey Broadwell wrote:
Currently, src/call_list.txt is a static file; any time new NCI
signatures are needed, it is edited manually. For very large APIs with
many unique signatures that may vary from platform to platform (OpenGL),
this is suboptimal.
On Mon, 2008-04-28 at 00:30 -0700, chromatic wrote:
I'm somewhat unconvinced, in general. For the OpenGL bindings, where the
build process has to build specific C code which links against specific
libraries, I can mostly see the point. For other bindings where it's
possible to build