Re: [MacPerl-Porters] Identifying Ported Modules

[Peter Prymmer <pvhp@forte.com>]

Matthew Langford wrote Mon, 10 Jan 2000 22:19:50 -0600 (CST):

> One difference between Solaris and MacOS is this:  without a compiler in
> Solaris, ALL your binary builds will fail.  In MacPerl, already adjusting
> to the reality that not all MacPerl users have or need to have a compiler
> handy, there is a system of providing Mac binary builds.  We are halfway
> between the Solaris extreme of requiring a compiler, and the ideal of a
> comprehensive source and binary distribution system.

While I recognize the ease of use ideal that you are expressing a desire for 
I'd say that unfortunately there may be too many variables in trying to provide
a really comprehensive binary solution.  In particular consider just the 
combinatorial explosion of supporting: Mac OS 7.1.* .. 9.* .. X across 68k and 
PowerPC, consider the possible differences in porting a module to the MacPerl 
app versus the MPW tool.  System DLLs have changed across such a broad range 
of OSes and architectures.   You would need a large build farm to test out 
everything and package it (something you alluded to later on).

> Ah, I hadn't thought of cases where XS modules could still work without
> binaries.  Would this be where the module provides an alternate, non-XS
> API?

For example the re module (pragma) in perl 5.005_03++.

> Binary modules, though, I don't think will go away.  I think they can,
> should, and will play a large part in MacPerl's future, extending its
> usefulness beyond the compiler-toting handful.
> 
> I guess we'll have to wait for ActiveState to pioneer something that works
> under Windows (which I understand is also grappling with binary issues),
> and then try to port it to the Mac.  There's something to be said for
> paying people to advance the platform.  

I agree with you here.  When Dick Hardt first proposed a packaged solution I 
thought that it was a Windows specific hack to replicate the functionality of 
CPAN.pm.  I was wrong.  The Perl Package Manager is quite helpful for 
compiler-less PC users to install XS based modules off the net (specifically 
the activestate site).  It has its limitations though: you'll be hard pressed 
to find any Alpha NT based ppm packages for example.  That said, I do think 
that the work Chris has put into installme and porting CPAN.pm goes a long 
way toward helping with this situation.  It is further enhanced by mmp and 
cpan-testers.  Do you think a cross-platform version of ppm would be helpful?  
How about resurrecting the `make uninstall` target for MakeMaker generated 
Makefiles?  That is something that would be helpful for perl site management 
even on Unix.  Unfortunately to `make uninstall` Foo::Module version 0.05
(in order to prepare for installation of Foo::Module v 0.06) I would need
to either have my original Makefile saved or at least the package replete with 
Makefile.PL and not everyone keeps a hold of everything like that (as it is 
CPAN now exceeds the capacity of a 650 MB CD-ROM).  Another problem with 
package management is static linking only platforms: they rebuild their perl 
binaries in order to link in an XS based module and doing a `make uninstall` 
for them is *really* tough (Mac OS and Windows are not so affected of course).

[snip]

> You were (are) ahead of your time.  I think it will happen.  Perhaps the
> chief challenge is arranging and storing a bazillion binaries, even though
> the libs for perl modules are often quite small.  I kind of like my idea
> of generating a binary by request through a network of CGI modules, and
> caching the generated binaries in a central location.  In other words, a
> collection of different boxes which can build binaries for their own OS
> and hardware.  But there are probably better ways.

That is not a bad way to try to do things, but who will provide such a thing?
See http://labs.perl.org/  and http://testers.cpan.org/ for the closest thing
to a collection of boxes.  Note that they do not provide binaries, perhaps 
they could.

Peter Prymmer


==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-porters-request@macperl.org