On Fri, Feb 12, 2010 at 2:06 PM, Geoffrey Broadwell <[email protected]> wrote: > So you will be writing C files and compiling them when OpenGL is loaded? In > other words, the machine you install Parrot on will need to have all the > build tools on it, just like the machine Parrot was built on? (This sounds > like the Inline:: family of modules in Perl 5.) If so, this will be a nice > short-term solution (which is great, we need one), but in the long term > we'll still need to implement a solution that doesn't require a C compiler > at runtime.
This not what I meant. Sorry for the ambiguity. The intention is to run nativecall.pir at library make time. If you were to look for an analogue in perl 5, it would be XS. It is still true that the library maker needs access to the same C compiler that was used to compile parrot, but non-trivial C-based PMCs already require this, so I don't consider it too much of a burden. > My other question here is if there is any caching done? You can look at the intended use case as a form of caching. >> * no need to link parrot against a frame generation library (jit based >> or otherwise) > > Whether we write it ourselves, or we use an existing solution, we will need > to do this at some point .... Some architecture/os combinations are not well supported by code generation libraries and some make these very difficult, if not impossible (using eg w^x). I consider it to be unacceptable to provide only degraded NCI functionality to these systems when it is entirely possible to provide the full offering. Dynamic frame generation still has advantages, but these should be limited to performance, not functionality. _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
