Re: [MacPerl-Porters] Identifying Ported Modules

[Chris Nandor <pudge@pobox.com>]

At 18.20 -0600 2000.01.11, Matthew Langford wrote:
>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.

Well, I am saying that I am not interested (currently) in going through a
lot of work to help those people, if compiling modules turns out not to be
too difficult.  In any case, if it is significantly easier than it is now,
then someone else can go through the work of helping them instead of me.
:-)


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

Yes, and that is the part I have tried to get the folks at modules@perl.org
to work with me on, with very limited success.  I do not chalk it up to
them being jerks or disagreeing as much as they are busy and this is not
something that interests them very much.  And now I am too busy to work on
it, so even though maybe one or more of them has time ... it is a vicious
circle.  :)


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

We are talking about two different things, MacPerl and perl on Mac OS X.
They are not necessarily directly related.


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


>I think it will not be significantly lowered,

I (for now) completely disagree.  It should be just as easy under Mac OS X
as it is under Solaris or Linux or AIX or whatever, which is certainly
significantly easier than Mac OS.


>The barrier isn't having a compiler handy, it's in the mindset,
>personality, and time choices of the user base.

OK, but the reason I do build binaries is not for people who don't have the
mindset as much as for the people who don't have the tools.


>Forcing every MacPerl user to tackle these is foolish, and sets the amount

Again, MacPerl ne perl on Mac OS X.


>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

Many people agree with you.  I don't happen to be one of them.  :)  I agree
somewhat, but not enough that I'll put much of my own time into it.  I will
help with MacPerl, because it is too hard for almost everyone to build
binaries on Mac OS.  And that's the only reason for me.


>If it wouldn't get installed under Unix (the binary target couldn't be
>built), why are we installing it under MacOS?

Oh, I see what you mean.  No, if there is some module that provides an
option of XS or non-XS then it very well may not fail.  It depends on the
makefile and such.


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

We don't know if a binary target is required without actually creating a
makefile and either parsing it or calling make.  The mere presence of .xs
files does not mean much.  And I am not about to tackle the parsing of the
Makefile that is created when Makefile.PL is run, since that would be Hard
And Subject To Much Breakage, and users simply looking at the output from
get and then deciding whether or not it can be installed safely is, well,
Not As Hard.

-- 
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

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