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

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



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?

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.

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.

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.

Arved


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

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