Front page | perl.perl5.porters |
Postings from October 2000
On Mon, 9 Oct 2000, Jarkko Hietaniemi wrote:
> It was pointed out to me that we have a nasty problem now that vendors
> are shipping Perl with their OSes. This Perl is most naturally
> compiled with the vendor's compiler kit. Now, if the compiler kit is
> 'unbundled' building any additional modules or trying to update
> existing ones will fail spectacularly because one or more of the
> compiler/linker name, compiler/linker flags will mismatch. In some
> cases it could be possible and even feasible to try to probe for
> alternative compilers, such as gcc. (*)
>
> I can see some ways how Configure could help in this (by trying to
> encapsulate some of the wisdom currently buried in the hints files for
> easier reuse later) but I think the right place to do such runtime
> heuristic fixing would be MakeMaker. Basically, try out $Config{cc}
> and if that fails, try to be smart and find out a replacement. Most
> often this would mean probing for gcc, but I can see also the opposite
> happening if somebody purchases vendor's compiler kit, and wants to
> start using that. (So maybe there needs also be a way for the Perl
> maintainer to sub-re-Configure these parts of the Config.pm?)
> Of course, sometimes mixing and matching libraries such as libperl,
> between different compilers simply cannot be done.
>
> (*) I will ruthlessly shoot down any attempt to discuss how evil
> vendors are by 'unbundling' their compiler kits. That is not the
> problem we are trying to address here. This issue comes up always
> when the compiler used to build Perl is not available.
Might I mention yet another approach? How about taking a lesson from the
microcomputer ports (specifically MacPerl and Windows perl) and provide a
convenient MakeMaker based way to easily distribute an extension from one
machine (that presumably has the expensive fully licensed compiler needed
to build perl extensions) to another less well equipped machine.
Activestate's ppm and MacPerl's droplets could serve as templates for such
an activity(?).
I guess that I have longed for a 'bindist' target to be in MM produced
Makefile's such that the resultant tarball when unpacked into the correct
location will give the target machine the same XS based capability as the
machine where the `make bindist` was run. Actually I'd like it too if
perl's Configure provided this (a bindist target in the Makefile). That
is, the thing that is currently missing from $installprefix is an ability
to use the resultant perl to XS-tend itself with a few choice modules to
produce a tar ball that is not all tangled up in the mess that I already
have in /usr/local.
My guess is that adding 'bindist' to MakeMaker could proceed without
harming an effort to produce a more dynamic Config.pm than what is current
practice.
Peter Prymmer
Thread Previous
|
Thread Next