Re: [MacPerl-Porters] Identifying Ported Modules

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

On Mon, 10 Jan 2000, Chris Nandor wrote:

> At 00.19 -0600 2000.01.10, Matthew Langford wrote:
> >But Case 1 may not go away:  as I understand it, the standard MacOS X
> >install won't include egcs/gcc.  Has this changed?
> 
> I don't think it matters.  Solaris doesn't come with any compiler at all,
> but it is rare to find a Solaris box without one (in my experience).  You
> download a binary installation, then either use it or build your own.

I don't understand what you are saying here, because I think you
ultimately agree with me about a binary distribution system; you have
generalized the concept better than I did.  As _any_ OS heads toward
mainstream users, compilers become more scarce.  I don't think Solaris
cares about consumer users.  (Consumer users could certainly care less
about Solaris!)  Linux, on the other hand, has responded to this reality
by coming up with RPMs and other binary build systems.  

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.


> >CPAN.pm/installme _should_ recognize this obvious and somewhat common
> >breaking point on MacOS:  an XS file but no Mac build.
> 
> But some modules might be installable and usable anyway, even if they
> contain an XS file.  I'd prefer to leave it to the user to decide.  The
> user is warned about XS, and it is easy to see if XS files are present.
> I'm not going to add something halting installation.  There already IS a
> warning present: the README and the printout of the file listing which
> shows any XS files.  If you are not sure if it will work, you first do a
> get Module, then you inspect it, then you decide to install Module or not.

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?

Yes, you can read the README, and it _may_ clearly warn about XS and
binary builds.  And yes, you can download the module and dig through the
directory.  But the first method is unreliable, and the second method adds
a lot of trouble.

I keep thinking of this:  it is far more common for a MacPerl user to harm
existing capabilities by downloading from CPAN than for a Linux or Solaris
user.  (Under Linux or Solaris, you can install it, and if it doesn't
work, you haven't lost anything.  No special safeguards or extra
precautions necessary.)  Current MacOS functionality depends heavily on
ported modules, and binary builds.  I'll concede ported modules may
completely disappear over time.   (um, what the line ending?  does MacOS X
use CR or LF?  and will 5.6 or some later Perl accept either/or/both?)

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.  



> >Even after MacOS X
> >arrives, CPAN.pm/installme can test for the existence of a compiler
> >(maybe it should be an ENV var set by the MacPerl/Perl install?).
> 
> When you configure CPAN.pm on a Unix box, you tell it where your compiler
> is.  If you don't give it one, your makes will fail.

Right.  Including "make install".  In MacPerl, "make" doesn't really fail,
and "make install" proceeds, when there is no compiler.  I don't think it
should, if there is a binary target.  The presence of a Mac binary, i.e.
the "make" target is up-to-date, is quite different from no binary.

Am I wrong?  Without a compiler, will CPAN under Unix install a module
which should have a binary component?  Or will it fail to install
anything?  Does it squawk, or fail/succeed silently?



> What I _would_ like to see is integration of CPAN.pm with the binary
> builds.  It knows you are using $^O eq 'MacOS' and when you ask to download
> Compress::Zlib it checks to see if there is a binary build, and if so,
> fetches it for you instead of the main distribution (there would be a
> preference for this behavior, or a prompt asking which to fetch, or both).

Yes, this would be a great step forward.  

> I have at least twice suggested it to the modules@perl.org people, saying
> that if this sounded good to them I would work on the code, but I never
> really got a response, aside from a couple of mails.  It would take
> cooperation with them, and I won't work on it if they aren't going to
> support it.  And I don't have the time (anymore) to work on it now.  The
> window of opportunity has passed, though I am sure it will come around
> again.

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.


> And as Paul, I also would not want to do significant work that would
> rendered obsolete by MacPerl 5.6.  Work has already begun on it, and I'd
> personally rather put my limited resources into it, instead.

I don't think 5.6 will make the whole issue obsolete, though perhaps with
MacOS X the problem of ported builds will go away.

I agree, though, that 5.6 is a higher priority by far.


> I suggest, though, that you send some mail to modules@perl.org about a
> system for using ported modules with CPAN.  Maybe it will get the ball
> rolling again.  If they get bugged enough, they might let it back on their
> radar.

Okay.  Does that mean I should also subscribe to modules@perl.org, and
lurk for a while, too?  Not only am I lazy, I'm impatient.  :)


--
MattLangford 



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