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

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

Thread Previous | Thread Next
Jesse Luehrs
July 11, 2012 12:51
Re: supporting untarring of extensions (was Re: Detecting duplicateextension directories)
Message ID:
On Wed, Jul 11, 2012 at 08:23:09PM +0100, Nicholas Clark wrote:
> 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.)

The problems I'm referring to have to do with the way we currently ship
dual-life modules. For instance: the that ships with core
doesn't include the code to monkey-patch UNIVERSAL::VERSION, because it
knows that since it's part of core, UNIVERSAL::VERSION already works the
way it wants it to. The version on CPAN *does* include this code, even
though it claims to be the same version number. This sort of thing is
not uncommon among the modules that we ship with core.

The issue here becomes that every exception like this makes it harder to
update core versions of modules when a new CPAN release is made. Sure, a
lot of this can be automated away (Porting/sync-with-cpan is incredibly
helpful here), but there is still a lot of manual intervention needed to
ensure that the automation works (because it will always be nothing more
than a guess), and there are various parts of it that aren't automatable
at all.

Moving the process for building dual-life modules toward "just drop the
same tarball you uploaded to CPAN into this directory" would be a
*great* help in simplifying a lot of the tedium involved.

Additionally, this would allow external packagers to have a much easier
time building a stripped-down version of perl for whatever reason (as
Fedora and whoever else seem interested in doing). All you would (well,
should) have to do would be to remove the appropriate tarballs from the
right place, and they would be gone. No need to fiddle with the build
system at all.

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

"Install" doesn't necessarily mean "install system-wide". We already
build miniperl, and then use it to build the rest of the extensions, so
building an executable and then running it isn't itself inherently an
issue. I don't see why we couldn't just install the stripped down (but
full) version of perl into a separate directory within the build
directory itself (similar to how home-directory installations currently
work), use it during the build process, and then remove it at the end of
the build phase.


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