[MacPerl-Porters] Identifying Ported Modules

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

On the Mac, CPAN can slit your wrists by downloading and installing
modules which do not work under MacOS, replacing ported modules which
_did_ work.  CPAN.pm currently cannot identify when this is happening,
either to prevent or to warn.

Removing this limitation would IMHO smooth the MacPerl user experience,
and further improve a valuable tool.

I can think of two cases which I think would cover most of the irritating
parts of the problem.

Case 1:  the module uses XS, but the distribution does not have a MacOS
shared library.  (I think we could test for this in ExtUtils::MM_MacOS,
perhaps earlier.  IMO, installme.plx should also croak when encountering
this scenario.)

If this happens, is there any reason to proceed with any further
conversion or installation?  Print an error explaining the module in
question must be compiled for MacOS, perhaps pointing to pudge.net/mmp.

Case 2:  the module does not use XS, but still needs porting.  A previous
version, which did require porting, is installed on the MacOS.  For this
case, I propose taking a special measure.  Since someone has to port it,
they could define a variable MAC_PORT_VERSION.  The MP_VERSION could serve
double-duty, to give us a Mac version number if necessary.  (I'd like to
see MacPerl's SaveAsDroplet automagically set the 'VERS' resource from the
VERSION variable if available.  Is this possible?)

Given such a variable, CPAN.pm could incorporate a MacOS-specific check
for it at the same point it compares version numbers.  [I think I remember
this behavior correctly:  if I tell CPAN to install a module whose version
is less than or equal to the current one, it will say I'm up-to-date,
right?] 

If MAC_PORT_VERSION exists in the old module, then CPAN.pm can print a
_warning_ message.  "Another version of this module, which required a Mac
port, is already installed.  Unless you know this module works correctly
under MacOS now, you should download the latest Mac version from
<http://www.pudge.net/mmp>.  Would you like to continue the install, or
cancel it to find the Mac version?"  (Continue install) (Cancel)

   If the continue/cancel branch is too much, CPAN.pm could automatically
   stop after the warning, and only a "force install" would continue.

   Or, if the continue/cancel branch is too little, a third choice could
   jump straight to http://www.pudge.net/mmp to find the latest Mac
   version.  This would require a certain module structure on MMP, and
   more changes to CPAN.pm, which nobody (including me) seems to be
   willing to tackle.

When a module "graduates" from needing a port to functioning naked, the
only thing needed is one force-install or install past the warning.

For no-port-necessary modules, everything works as it has.

For ported modules, a few OS-specific lines in CPAN.pm and a new variable
in each ported module is required.  In fact, the same system could be used
on other platforms to warn about replacing platform-customized files with
platform-contrary ones.  

The last piece of the puzzle is how to handle the ported modules already
in place.  My vote is to _not_ handle them.  As new versions of modules
are ported, they can add the variable.  All the big packages built into
MacPerl can wait for MacPerl 5.6, which I hope will be out in the first
half of this year.  By the time a reasonably stable MacPerl 5.6 exists,
the changes would be rolled into CPAN.pm and all or nearly all ported
modules would have a port version variable.

Why not do this?

--
MattLangford 





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