Re: [MacPerl-Porters] Identifying Ported Modules

[Chris Nandor <pudge@pobox.com>]

At 22.19 -0600 2000.01.10, Matthew Langford wrote:
>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,

I am saying that lack of bundled compiler has not proven to be a
significant barrier to people who use a compiler.


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

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


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


>Yes, you can read the README, and it _may_ clearly warn about XS and
>binary builds.

I was talking about the cpan-mac README, which warns you.

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

The second method is easy.

  cpan> get Module::Foo

That prints out a list of all the files as they are unpacked.  Just glance
for .xs or .c or .h files, and if they are present, figure out what they do
before going on to "install Module::Foo".


>(um, what the line ending?  does MacOS X
>use CR or LF?  and will 5.6 or some later Perl accept either/or/both?)

It is unclear in my research what newline will be used where.  perl 5.6
does support LF or CRLF, and I imagine eventually it will support CR, too.


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


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

You may not subscribe, it is a closed list for the head CPAN/module people,
but you may post.

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