Let me start with answering question (2). You say that if you want to include package Foo in your distribution and Foo depends on Bar1, Bar2, Bar3, then you don't actually want to include Bar* in your distribution as well ("certainly don't want them all")? That doesn't make any sense to me. Foo declared the dependency with a reason. But maybe I'm misunderstanding you.
In Perl, there is essentially three types of library directories: core-, vendor-, and site lib. They are intended for use by the perl core, the vendor and the site admininstrator respectively. Since you intend to create a binary package of perl, you're the vendor. I suggest you use "cpan" to install your custom packages into the vendor directory and ship them as part of the package.
On some level, I actually like the idea of including extra packages in the base perl distro and then compiling them as part of the core installation. There's a couple of things that can cause trouble with this:
In the current development branch of perl, the directory structure has been reorganized to make maintenance of the modules that live both in core and on CPAN easier. Where there used to be a giant lib/ directory and an ext/ directory for XS modules, there is now:
ext, dist, and cpan are organized in subdirectories which mimick an extracted CPAN tarball as closely as possible (usually ignoring the Makefile.PL). Lots of hardcoded information has been eliminated and missing Makefile.PL's are usually auto-generated. Just extracting a CPAN distribution is not likely to just work yet but the amount of fuzzing to get it included should be pretty low nowadays. Note that there is no stable release of perl that features this reorganization. You can experiment with the recent 5.11.X development releases.
Cheers
Steffen
In reply to Re: Building perl for appliances
by tsee
in thread Building perl for appliances
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |