Front page | perl.perl5.porters |
Postings from February 2012
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 config.sh to remove all the unwanted
> pure-Perl dual life modules before building to avoid building them, and
> before making Config.pm 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
around.)
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 config.sh file is written, at the end of the normal
Configure process, so no Config.pm 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
reader.)
--
Andy Dougherty doughera@lafayette.edu
Thread Previous
|
Thread Next