Re: [MacPerl-Porters] Identifying Ported Modules

[Matthew Langford <langfml [at] eng [dot] auburn [dot] edu>]

On Tue, 11 Jan 2000, Peter Prymmer wrote:

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

Things aren't so hopelessly complex as you fear, because perfection need
not be attained.  Just because there is no way to write large bug-free
systems of code doesn't mean we junk our computers.

For example, consider that we _already_ support that combinatorial
explosion of systems you mention:  from MacOS 7.x to 9.x, 68K to PPC, MPW
and MP app.  I'm glad it wasn't considered too daunting to make MacPerl
(5) in the first place!

As you know, all that is really relevant for most modules is what flavor
of 68K versus PPC.  As far as I'm concerned, CPAN makes no sense for
statically compiled installations.  Also, IMNSHO, 68K is very close to
obsolete, but perhaps CFM68K has a year or two of life left.

Finally, the build farm I alluded to is not a cathedral, it's a bazaar! :)  
(apologies to Eric Allman and Larry Wall, for different reasons)  What I
mean is, if you want to see binaries for your platform, hitch up your own
server!  (Subject to signup and verification, so at least a system of
digital signatures come into play.)  No one site would _build_ all the
binaries, though it might store what's available.

Furthermore, for an even greater touch of reality, there's no requirement
that a build for any given platform happen in realtime.  If a platform
still requires significant porting work, the CGI queues up a binary
request.  When the binary is built, it gets distributed and cached,
alongside binaries for other platforms which can get built in
semi-realtime.  If there are platforms that entirely scorn pre-built
binaries (even Solaris would probably not do this, and certainly not
Solaris x86), then no binaries would be available or auto-built for them.
If you prefer to build your own binaries, fine.  The raw dist is available
as always.


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

How does this work in terms of a makefile?  Does the "make install" target
include a binary or not?  If it does, then I contend the Mac
make_install() should fail just as Unix does, when the binary is not
found.  If not, then both should succeed.

I'm mystified why this is controversial, though hopefully I'll find out
tomorrow.

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

Absolutely!  CPAN.pm and installme are both giant steps forward for
MacPerl, just as CPAN.pm provides extension capabilities for Perl beyond
any other language I can think of.  I am eager to see them improved
precisely because they are so useful and important (to me, at least--it
seems few others share my eagerness to put effort into them).


> Do you think a cross-platform version of ppm would be helpful?  

I don't know.  I haven't had much opportunity to work with ActiveState
perl or ppm.  To be honest, I didn't know ppm already existed.

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

IMO, if Foo::Module v0.06 _needs_ v0.05 uninstalled before it can proceed,
it would have to include v0.05 install info, and do the uninstall itself.

In general, that shouldn't be necessary.  All you need to know is which
files will be replaced by Foo::Module v0.06, whether from Foo::Module or
from anything else.  Save them in the uninstall archive, along with a list
of files installed by Foo::Module v0.06.  This last list of files affected
will also need to get added to a master undelete file.

A key piece to this is the uninstall cache.  Uninstall capability is only
available for a rolling set of installs; how big a set is determined by
how much space you are willing to devote to the uninstall cache.  CPAN.pm
already has caching in place for the source and build caches.

Last, it is obvious that packages installed before the uninstall-capable
CPAN.pm cannot be uninstalled.  

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

See one of my other rambling posts about handling this.  Either don't try
to handle it, or save the whole monster binary for each install.  It
actually makes caching easier, though much less space efficient.  But hey,
static linkers weren't trying to save space in the first place, right?


> That is not a bad way to try to do things, but who will provide such a thing?

Whoever wants a binary, or is willing to provide binaries for their
platform.  Or for other platforms, given a cross-compiler.  If no one
steps up for a given platform, it gets left out.  Such a platform is no
worse off than now.

It is quite possible that for now, only MacOS and Windows have a broad
enough user base to really desire this system.  (But again I note the
popularity of RPMs for Linux.)  Even though small in numbers compared to
Unix users of Perl, the Perl users on consumer OSes are already more
diverse.  There are people on the MacPerl mailing list who are intimidated
by any Unix, much less by compiling and installing software on Unix.  
These people already fall outside the scope of Unix perl users.  Rather
than hoping they go away, or somehow geek up with the arrival of MacOS X,
I think we should embrace them.  Everybody on this list (except me, I
guess) has already done excellent work in this regard.

I never meant to minimize the excellent work done by others.  But, at the
same time, I am bold enough to think there is room for improvement, and
even bolder to think I can see a few such places.


--
MattLangford 


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