Re: Two-stage build for CPAN modules

2022-6-17 16:13 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> 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.
>
>
Interesting idea.

Perl for Traditional Bootstrap and Perl for Modern Application.

For example,

Perl for Traditional Bootstrap -> OpenSSL -> Perl for Modern Application.

• Two-stage build for CPAN modules by Paul "LeoNerd" Evans
• Re: Two-stage build for CPAN modules by Yuki Kimoto