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

Re: [MacPerl-Porters] perl internals as shared library?




Arved wrote:

> Quoting Peter Prymmer <pvhp@forte.com>:
> 
> > Matthius has mentioned that he is considering converting the MacPerl build
> > process to a pure CodeWarrior project format that might obviate the need 
> > for MPW altogether.
> > 
> Could be interesting. :-) What would happen here? Build a miniperl as a CW 
> plugin, and then take it from there?

We do not know yet.  I should have prefaced that ad lib speculation of
mine with <warning disclaimer="speculation ahead"> tags or somesuch.
The need for MPW may not be obviated for all I know.  (Careful observers
will note that I did manage to misspell Matthias' name at least :-)

> Even though I've got Codewarrior myself, I'd like to urge that some kind
> of support be retained for MPW. Apple MPW, that is. Note I say "some kind"
> of support. I won't vouch for CFM68K (our extension builds with SC have
> been inconsistent), but I have no reason to believe that MrC isn't up to
> building MacPerl. I think being able to say that the entire process -
> MacPerl C source to a MacPerl app or tool running scripts - can
> be accomplished with free tools is attractive. And not everyone can
> afford Codewarrior. In addition, keeping up with the Jones's might be as
> simple as issuing patches, but if you need CW to build, how many folks will
> that help? And so forth.

According to any Codewarrior doc I've read it supports the build of
Mac applications and MPW tools.  One needs to distinguish one's build 
environment from one's intended binary characteristics I think.  AFAIK
MacPerl requires MWC and until someone ports it to MrC it won't build 
there.

BTW I never got to respond to the request for comments on the CFM68k 
discontinuation: I'd like to retain it (I do use it) but I would prefer
that anything that slowed down MacPerl development be skipped, including 
the code fragment manager if necessary.

> I'd be willing to help with this side of things, certainly.
> 
> Brings up another point. Our MacOS-side extension builds have historically
> suffered from not being able to take advantage of Test::Harness and hence
> 'make test'. Are we planning to rectify this as part of a new extension
> building process? Speaking of which, if the main build goes to CW, how is
> that going to work with 'perl Makefile.PL'? There's been talk about
> perl plugins for CW, and XML import/export, and being able to read makefiles,
> but as near as I can tell that's all vapourware so far. Just curious.

I am perhaps somewhat less informed of vapourous things than you hence I am 
less qualified to answer your rhetorical quesiton.  Nonetheless, repeating
what I said above: building with MWC does not preclude the construction of
an MPW-tool-type perl for which `perl Makefile.PL` in the MPW shell 
makes perfect sense.  I've never encountered another perl platform for which
building perl with one compiler works without a hitch to build non-trivial
XS modules using a different compiler though.

> But, with respect to tests, one suggestion I have is to modify Test::Harness
> slightly so instead of piped opens, it just requires the .t files, in a loop.. 
> Each t file in turn could be placed inside a special test package, and the 
> symbol table for that package could be cleared after each t file. The only
> other gotcha to look out for is that some t files contain "exit" statements,
> which would have to be negated somehow. But in principle this works well
> enough, and I've used it to generate the same kind of output for a test as
> one sees on a Unix box. Just an idea.
> 
> Just brainstorming. I guess what I'm saying is that if Matthias has some
> peripheral tasks of this nature that he wants to farm out, I'm a volunteer,
> and maybe there's others.

Maybe there are and maybe there are not.  I do recall when Bill Middleton 
used to be able to report back to Matthias regarding MacPerl build success 
or failure.  I too would like to help out in any way I can - but that may 
not be much for a variety of reasons.  I think we all (on this list anyway) 
owe it to Matthias to try our hardest to build MacPerl from the src kit and 
*then* speculate about how it might be changed :-)

Unfortunately Chris, I am going to be in a Panel discussion of "Administering 
a Perl Installation" at the same time on Monday that you and Matthias were 
going to speak.  If there will be a BOF (or even something less formal) 
that'd be nifty but I note that I'll be in a BOF with Mainframers and others 
Monday evening at 8 PM at the TPC.

Peter Prymmer

>  This mail was sent through the Nova Scotia Provincial Server.
>  http://nsaccess.ns.ca/mail/ (in development)

nsaccess?  What wiseacre named that computer? :-)




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