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. There are (at least) two problems with this: > > 1. Even if a large API is disabled (because it wasn't detected, or > because Configure.pl was called with a --without-foo option), the unused > NCI signatures are still compiled and included in the parrot library -- > potentially several hundred K completely wasted. > > 2. When generating signatures from system headers, call_list.txt will > need to be modified at Configure time anyway, so pretending it is static > makes no sense. > > For this reason, I believe we should add a config step that concatenates > src/call_list.txt from a directory of fragments. The attached patch > makes just that change, splitting the existing call_list.txt into > several smaller pieces in the process. I have checked that running > Configure with the patch will produce a call_list.txt that contains the > same signatures, though in a different order. > > Once this basic concept is accepted, then OpenGL (and potentially other > libraries) can start generating the call_list fragment from system > headers, and in particular not generating a fragment at all if OpenGL is > disabled. This will come in a separate patch. (Currently the OpenGL > fragment contains only a handful of signatures, just enough to get the > triangle to spin. The generated version of opengl.in will contain > 200-250 signatures.)
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. This just multiplies files based on which library needed a specific signature first. I'm not sure that will help us maintain them. 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, 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. -- c
