[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] Perl Shared Library (was Re: [MacPerl] ports and builds)



In article <mac-perl.86d84i8sdw.fsf@gwaihir.ee.ethz.ch>, Matthias
Neeracher <neeri@iis.ee.ethz.ch> wrote:

>In article <199901132314.PAA57728@scv4.apple.com>, Steve Zellers
<zellers@apple.com> writes:
>> 1) I'd like to see perl on the mac distributed as a pure shared library.  
>> This would allow plugins to operate in different application contexts, 
>> and would allow freeze-dried perl applications to not have to bundle the 
>> entire perl runtime.
>
>While I do agree with the basic feeling that Perl should be available in a more
>embeddable form and actually am working (slowly) toward that goal, the actual
>distribution logistics are going to be difficult.

I've been thinking about this for a while. This may already be what you
have in mind, but just in case, a few comments:

Under Unix and Win, the Perl app itself tends to be tiny--the bulk is in a
shared lib, and this tiny app just embeds and invokes the lib (as I'm sure
you know). I tend to be against breaking up Mac apps into multiple pieces,
but in this case there would be significant advantages: 

1) Multiple Perl apps could run simultaneously without (or independent of)
threading in the interpreter. They would each have a large memory
footprint, but a small disk footprint which would be ideal for
distribution. 

2) Also, as is the standard argument, updated version of the shared lib
would automatically benefit all of these apps. 

This is all standard stuff.

3) More importantly, though, is this: writing a "real" Mac app (ie, a
Toolbox-heavy app) presently involves a lot of shenanigans which are the
result of living within the MacPerl app, such as removing and restoring
menus, preemption issues with spinning the cursor, etc. With a library,
the "standalone" versions of scripts would naturally omit the MacPerl
stuff which is really not MacPerl-as-perl-interpreter but is
MacPerl-as-perl-IDE. This would simplify things and maybe enhance
stability.

>> 2) Perl libraries (/usr/local/lib/perl5/*) should be placed relative to 
>> this shared library
>
>What I've experimented with is a symbolic link in the perferences folder.
>I prefer not to install major directory trees in the system folder

Isn't there now an "Application Support" folder in the System Folder? This
seems like the appropriate place for things, with the possible option of
putting an alias here instead of the actual hierarchy.

Alternatively/additionally, since the Mac is quite good at locating things
by type and creator, it would be snazzy to go looking for the hierarchy if
things are not where they are expected to be (and finally prompting the
user to locate them if this fails). It just depends on how far you want to
go.... 

>In particular, I would be interested in finding out how Perl is
>going to fit into MacOS X (my understanding is that it's shipping in MacOS X
>Server, would you happen to know who is responsible for that port?).

Hopefully you'll get the full scoop, but my guess is that the version in
MOSXS is minimally changed from the standard Unix perl. If this is right,
there will still be a need for some MacPerl (aware of Toolbox
functionality, and maybe later Yellow Box interaction), although there may
be much less work involved than there is at present. On the other hand, if
Apple paid you to do this (or if they paid someone else to do it, with
your input), then this might be optimal. Just thinking out loud....

JEff
-- 
__________________________________________________________________________

Jeff Clites                Online Editor           http://www.MacTech.com/
online@MacTech.com         MacTech Magazine
__________________________________________________________________________

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch