Re: [MacPerl-Porters] Identifying Ported Modules

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

On Tue, 11 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 am saying that lack of bundled compiler has not proven to be a
> significant barrier to people who use a compiler.

I see.  What I was trying to say is that the number of people who aren't
interested in using compilers will only go up.  Even though they _could_
use a compiler (custom install MacOS X with the full BSD including
compilers underneath), they will choose not to.  MacOS X will not
magically turn consumer users into uber-geeks.  

The second part of what I was trying to say was that CPAN.pm could stick
its head in the sand, and limit itself just to compiler users.  Or, with a
little work, it could add a little binary package support.  

MacPerl has proven useful to many people who don't use compilers.  MacOS X
will probably not drastically change the fraction of people who (don't)  
use compilers.  So the need for binaries will not go away.  Stop providing
binaries, and we reduce MacPerl's usefulness and user base.  Why go
backwards?

All this is independent of MacPerl/MM_MacOS.pm/installme.plx's behavior
regarding binary files and installation, which is really what I care about
right now. I'll have to think about what sort of system I would want to
propose.



> But I am not going to provide Mac OS X binaries if they are easily built
> with gcc/ecgs/etc., and I would not encourage others too, either.  We
> provide Mac OS binaries pretty much because the barrier to do it yourself
> is far too high for most users.  If the barrier is significantly lowered,
> as it seems it might be, then I would not distribute binaries.
> 
> That may not apply to the Mac toolbox libraries, which still may have a
> significant barrier (having the right Mac OS libraries, headers, (separate
> compilers?,) etc.).

I think it will not be significantly lowered, and I think it would be a
mistake to stop providing binaries.  (I guess that's obvious from what I
wrote above.)

The barrier isn't having a compiler handy, it's in the mindset,
personality, and time choices of the user base.  MacOS X users, if
they approach the numbers of MacOS users, will not be more "geeky",
more willing to dig into programming compiled languages, more
willing to spend their time learning C, etc.  Issues like those are
the major limit to MacOS compiler users, not availability.  (Conversely, I
argue that if MacOS X users ARE forced to look more like Unix users, MacOS
X's user base will be about as small as other Unix variants.  It will have
failed, for Apple's purposes.)

Forcing every MacPerl user to tackle these is foolish, and sets the amount
of work required to join the community much higher than it has been.  It
reduces the size of the MacPerl community more than it needs to, and
reduces it from its current small state.  Most of all, it is needless.
Under Unix, requiring a compiler was a reasonable assumption, since
everything else makes that assumption.  But Unix has a tiny market share
among all computer users, partly due to such draconian assumptions.  
MacOS assumes much less.  Because of this, the MacPerl community has
adjusted to the MacOS environment, and provided binaries.  IMHO, this
should continue.

I think it is highly desireable, both for the acceptance of Perl by MacOS
users, and on _any_ platform with consumer users (Windows, MacOS, and 
Linux), to provide binaries.  It makes Perl easier to use.  It brings
MacPerl down from the geekoid level of C/C++ toward AppleScript and xTalk
scripting.


However, after going on at great length about providing binaries, I
realize this is a future issue.  It can wait at least until MacOS X is
available.  It is relevant only in the sense that if we mistake a problem
going away, we may fail to address it in a timely manner.



> >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?
> 
> That, or perhaps the XS is for some extra part which is not needed, or
> maybe it is just example or experimental code, or ... .  I don't know.  :)

> >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?
> 
> It will try to make, and it will die.


If it wouldn't get installed under Unix (the binary target couldn't be
built), why are we installing it under MacOS?   If there is a portion of
the module which will still work, how is this installed under Unix?  Why
don't we do it the same way under MacOS?

If a binary target is required, but not present, then MacPerl should stop
the installation just as Unix does.

If MacPerl cannot tell when a Mac binary is present, then the way Mac
binaries are distributed and the way MacPerl searches for binaries should
be patched to allow that to happen.

What am I missing?



--
MattLangford 


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