Front page | perl.perl5.porters |
Postings from February 2012
On Thu, Feb 02, 2012 at 04:02:26AM -0500, David Golden wrote: > On Thu, Feb 2, 2012 at 2:47 AM, Todd Rinaldo <toddr@cpanel.net> wrote: > > 2. Also strip html docs and man pages as they're duplicate to perldoc. (Is there an opinion on which forms of the docs need to be shipped with the product to comply with the license?) > > Please forget the "license" question -- I'd really mean "spirit of the > license", not "letter of the license". Personally, I think "man" for > the bin scripts would be good to have and perldoc for the rest is > fine. What he says. Note also that (currently) use diagnostics; relies on finding an installed perldiag.pod As it needs pretty much the entire file to function, I can't see a way to bundle perldiag.pod into it that doesn't end up with installing 207K pod twice for a full installation. > > IMO, it would be cool if I could somehow tell Configure not to build/install anything that is dual-life. I'm not sure if a non-dual life perl would be stable enough to build the dual life modules if I did that. To me, this is the sanest approach to building out a core perl, allowing for dual-life modules to be updated separately. > > It's not possible to build everything without dual life modules, since > some are essential to the toolchain. I can't see anything preventing > only a subset being installed, however. Yes, it would have to be a restriction on what's installed. However, right now, it's not possible to tell Configure not to build non-XS modules. Everything it finds, it builds. The really historical assumption was that only XS modules were in ext/, and the question that mattered was "dynamic, static or don't?" (as I understand it) When non-XS modules were added into ext/ (And then dist/ and cpan/) the path of least resistance was to always build them, as a) the rest of the extension handling in Configure assumes static or dynamic b) there isn't a problem with being unable to build them because C libraries or APIs aren't available. So currently one would have to munge config.sh to remove all the unwanted pure-Perl dual life modules before building to avoid building them, and before making Config.pm to avoid having an installed %Config::Config that says that they are there. (Although whether anyone's code interrogates %Config::Config for that sort of thing, I don't know.) > > I don't think I could provide a patch in the short time before the coming code freezes for 5.16, but I was considering taking this project on for 5.18. I'm also not sure how such a patch would be received if I did make it, since p5p would then be providing a way to build a severely stripped down perl. > > IMO, vendors are doing this anyway, so why not have a sanctioned > (maintained!) way to do that. > > If you are looking to take it on, I would point you to the various > "install*" files in the source . They would need a lot of love (or > possibly a complete rewrite) to support the ability to install only a > subset of what is built. Yes. Right now the logic for which modules get installed is in installib() in ./installperl. The logic for which man pages get installed has been moved from ./installman to Porting/pod_lib.pl. Some duplicate functionality of ./installperl and ./installman has converged, but ./installhtml is a still law unto itself. I'd been working on trying to make all this sane (ie one list of what gets installed), but obviously there are a zillion other demands on my time, and not enough hours in the week. ./installman is pretty clean. ./installperl is closer. ./installhtml is a mess. Nicholas ClarkThread Previous | Thread Next