develooper Front page | perl.perl5.porters | Postings from July 2012

Re: supporting untarring of extensions (was Re: Detecting duplicateextension directories)

Thread Previous | Thread Next
Nicholas Clark
July 11, 2012 12:23
Re: supporting untarring of extensions (was Re: Detecting duplicateextension directories)
Message ID:
On Wed, Jul 11, 2012 at 02:11:01PM -0500, Jesse Luehrs wrote:

> > 5) everything is sufficiently set up now that the rest of the core build
> >    system will pick up the new modules. This should work for simple things
> So by "arbitrary extensions" here, are you referring to things that
> already exist as dual-life in the core, or entirely new modules to add
> to a custom distribution? (or both?) My personal interest is in getting
> as many dual-life modules as possible extracted out of the main build
> process, because keeping things in sync with their CPAN versions is
> quite a pain, due to the amount of changes that are necessary to get the
> distribution to build in-core.

No, I really meant things in a custom distribution.

I'm also not sure whether this really solves the existing problems of
building things in core. (Which I wasn't aware of). Specifically, one
is still trying to build against an *uninstalled* perl, whatever build
system one is trying to use for bootstrapping modules in this situation.

Other than Configure probes, what is causing pain for dual life modules
sitting in the existing build process? We must fix that, I agree.
But I'm not aware of the specifics of the problems, which makes it hard
to help.

(This stuff is hard to get working at all, as it has to work on 3 disjoint
families of platforms, which make the differences between Linux and AIX seem

> I think I can see how this would be possible - keep a very minimal
> (doesn't use perl) build process available for building just perl and
> the toolchain modules, to allow for bootstrapping. Then, just build and
> install that "perl-minimal", and that will allow you to run the full
> build process, which builds everything with perl via CPAN tarballs. Is
> this what you are envisioning?

Aha. You're assuming install. No, specifically *not*.
In that, I think that that approach isn't going to work for any Linux or
*BSD packaging system trying to clean build a new version of perl into
a (fake) root from which to build binary packages. Because it can't assume
that the newly built system is allowed to run in place as part of the

configure, build, (test) and install really need to stay as 4 distinct

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About