Front page | perl.perl5.porters |
Postings from July 2012
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 tiny.) > 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 build. configure, build, (test) and install really need to stay as 4 distinct phases. Nicholas ClarkThread Previous | Thread Next