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

Re: Reaction to Redhat/Fedora modified releases

Thread Previous | Thread Next
Andy Dougherty
February 2, 2012 09:15
Re: Reaction to Redhat/Fedora modified releases
Message ID:
On Thu, 2 Feb 2012, Nicholas Clark wrote:

> > > IMO, it would be cool if I could somehow tell Configure not to 
> > > build/install anything that is dual-life. I'm not sure if a non-dual 
> > > life perl would be stable enough to build the dual life modules if I 
> > > did that. To me, this is the sanest approach to building out a core 
> > > perl, allowing for dual-life modules to be updated separately.
> > 
> > It's not possible to build everything without dual life modules, since
> > some are essential to the toolchain.  I can't see anything preventing
> > only a subset being installed, however.
> Yes, it would have to be a restriction on what's installed.
> However, right now, it's not possible to tell Configure not to build non-XS
> modules. Everything it finds, it builds. The really historical assumption
> was that only XS modules were in ext/, and the question that mattered was
> "dynamic, static or don't?" (as I understand it)

Yes, that's it.  There was no CPAN, and there were no independent modules 
to bring in.  Non-XS things simply went into lib/.

> When non-XS modules were added into ext/ (And then dist/ and cpan/) the
> path of least resistance was to always build them, as
> a) the rest of the extension handling in Configure assumes static or dynamic
> b) there isn't a problem with being unable to build them because C libraries
>    or APIs aren't available.

Right.  And also, if p5p were including them in the core, then we expected 
them to be installed as part of 'standard' perl.

> So currently one would have to munge to remove all the unwanted
> pure-Perl dual life modules before building to avoid building them, and
> before making to avoid having an installed %Config::Config that
> says that they are there. (Although whether anyone's code interrogates
> %Config::Config for that sort of thing, I don't know.)

Yes.  It's quite easy to do, actually.  (I think it's a bug that 
-Dnoextensions doesn't apply to nonxs extensions, but it's easy to work 

For a concrete example, suppose you want to exclude Term-ANSIColor and 
Text-Tabs.  All you have to do is create an executable file "config.over" 
in the build directory with these two lines;

    extensions=`echo $extensions | sed -e 's! Term/ANSIColor ! !' -e 's! Text/Tabs ! !'`
    nonxs_ext=`echo $nonxs_ext   | sed -e 's! Term/ANSIColor ! !' -e 's! Text/Tabs ! !'`

The config.over file can contain any valid shell commands.  It is 
executed before the file is written, at the end of the normal 
Configure process, so no munging is required.

(If you try this specific set of exclusions, the build will fail when
it tries to run lib/unicore/mktables, as that requires Text::Tabs.
Sorting out all such dependencies is left as an exercise for the

    Andy Dougherty

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