Front page | perl.perl5.porters |
Postings from June 2022
A thought occurred during the discussion of how to handle https "out of the box", in that a bundled module (e.g. Net::SSLeay) would be tricky because we'd have to handle the configure-stage of its Makefile.PL in a different way. This is because bundled CPAN modules don't really get a configure stage so they don't build the same way as installing it via the regular CPAN client. This has in the past caused me trouble; e.g. when we imported IO::Socket::IP into being a core module. It ultimately all comes down to the trouble of needing a fully installed and available `perl` in order to run those scripts, which isn't yet available while building and installing said perl. It's a bootstrapping problem. But I wonder - why do we need to do this for *all* of the bundled modules? Yes admittedly modules like Scalar::Util or Socket, being so fundamental to everything else, need to work this way. But could we have a "second stage" for more regular building *as if* done by CPAN.pm, for bundled modules that are supplied "for convenience". E.g. modules like IO::Socket::IP or whatever else we think we'd include for SSL support. These would build in a second stage, after the `perl` binary itself is all finished and installed - core modules and all - and so it could just run the exact same sequence of build steps as would happen when CPAN.pm installs it. -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/Thread Next