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 Parrot without even having the libraries installed, install 
> them later, and still use them (everything but the test libraries and 
> OpenGL), there's little benefit.

Here you seem to be assuming that we will already have all of the NCI
signatures we will need for any new library we come across.  My
experience (and my reading of comments in call_list.txt) is that that is
very rarely true.  At any given time, NCI seems be missing a handful of
odd signatures needed by any new library we come across, which means
that call_list.txt has to be updated and Parrot rebuilt anyway.

nci.o is already needlessly large for users that don't need to load a
pile of libraries; trying to include all "common" signatures will just
make that worse.

> This just multiplies files based on which 
> library needed a specific signature first.  I'm not sure that will help us 
> maintain them.

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?

> As you say, the real problem is that we have a static list of NCI thunks 
> known 
> only at compile time.  If it's easier to work on the OpenGL bindings in tree 
> with a change like this,

It is.

> I can live with having a separate library of 
> signatures merged in somehow, but I'm not sure that benefit outweighs the 
> pain of splitting up everything else, especially given all of the hope that 
> Kevin succeeds in his GSoC project.

I'm trying to take advantage of the time I have now to get this OpenGL
binding working well.  As many of you can attest, my personal project
time is very bursty -- I can't wait until the end of the summer,
especially since there's no guarantee of success (though definitely my
best wishes for success).

I'm not trying to make the best choice for Parrot 1.0.  I'm trying to
make the best choice for Parrot 0.6.x.


-'f


Reply via email to