I would be very greatful if you worked on this. =-)
This came up a few months ago with Tcl - there are several inter-related PMC, just like the Perl* PMCs (which only work because they are NOT dynpmcs...) - you cannot compile them individually, you must do them all at once. I tabled working with dynpmcs due to a lack of tuits in addressing this problem.
Thanks. =-)
Mattia Barbon wrote:
[got a failure, sorry if this is a duplicate]
On 15 Aug 2004 10:11:11 -0000 Leopold Toetsch via RT <[EMAIL PROTECTED]> wrote:
Mattia Barbon <[EMAIL PROTECTED]> wrote:
Hello, I am not sure about this patch. It splits part of Parrot_load_lib into a Parrot_init_lib(Interp, load_func_ptr, init_func_ptr) where load/init_func_ptr are pointers to the function loadlib calls. The objective is allowing dynamic PMCs linked inside a larger library or maybe an executable. For example Ponie might have Perl5IV, Perl5PVCV, etc. PMCs linked inside libponie,
For PMC libraries I'd rather have that done in the PMCs init code. This could be automated for a bunch of PMC files of one language. E.g. a utility concats the .c files generated from .pmc and chains the init functions, so that one init call registers all PMCs.
Maybe something like this (exact syntax up in the air):
pmc2c2.pl ... --dump pmc1.pmc pmc2c2.pl ... --dump pmc2.pmc pmc2c2.pl ... --dump pmc3.pmc pmc2c2.pl ... --c --library-name baz pmc1.pmc pmc2.pmc pmc3.pmc # outputs the PMC code in pmc1.c, pmc2.c, pmc3.c # puts a merged class_init and Parrot_lib_baz_load in baz.c
This will also allow solving the problem in the patch to Pmc2c.pm (can't have two dynpmc A and B, A declaring an MMD function with B and B declaring one for A).
Will work on it.
But your solution seems to be just a generalization of this.
It is not. Yet. But this patch (or something like this) is needed to implement PMCs linked into an executable (statically linked ponie), or into a shared library that also contains other runtime functions (a shared libponie.so(.
Regards Mattia
