Progress is being made on that front.
I started by creating /experimental/static-libperl on SVN, and cloning /CamelBones into that. Never work without a net! :-)
I've simplified the project structure, and removed all of the dynamic-loading "support bundles" stuff - the framework now links directly against libperl. But that won't cause portability problems now, because we're linking against our own static libperl this time. That's what the new "relocatable" feature in Perl
5.10 is all about.
I've added a target that configures, tests, and builds Perl, then stages it to $BUILD_ROOT/Perl. I've verified that it's relocatable by running it directly from there - it had no trouble finding its
, where an earlier version would have. In Perl 5.10, a path in @INC that begins with ".../" is resolved as being relative to the "perl" binary. Finding libperl, of course, is not an issue when it's static-linked.
Next step - link the framework to the static libperl, and try to build and test CamelBones.pm with the result. Since the staged Perl will run "in place" without having to be
installed, it should be able to run the CamelBones module's
Makefile.PL and tests. (Tests, once they're running at all, should only run on the "Debug" configuration.)
After getting the module up and running, I'll try embedding the framework & module into an app. The 64k question is how to use libperl's embedding api to set the binary path, so that at run time, Perl's @INC will point to the framework Resources/ dir. I hope it's as simple as just passing the correct path as the first element in perl_parse()'s argv array.