There are no plans to carbonize MacPerl. I've not seen the need anywhere;
although if it won't play nicely with Carbon apps under Mac OS 8/9, that
would be a reason. Do you have custom shared libs that MacPerl is calling,
through XS or something? Or is it using the MacPerl toolbox? I've never
heard of any problems with a non-Carbon app calling a Carbon app.
So if MacPerl is Carbonized, there are a few things to consider.
* Alan Fry is leading the charge to look into reworking the editor, and
that effort would need to consider Carbonization too, if the main app is to
be Carbonized.
* There's GUSI 2 (as well as other external libraries, like AEGizmos,
MoreFiles, etc.), and I don't know if it is Carbonized.
* We would likely need to make sure that any Carbon-specific calls are
#ifdef'd, because we don't want to drop Mac OS 7.6 support unless we really
have to.
* I would not want Carbonization to slow down MacPerl 5.6.1r1 (the first
release of MacPerl based on 5.6.1). If necessary, we could have a separate
Carbon branch in CVS, or something, and merge it back later.
Hm, there are probably more issues I can't think of at the moment, but I
think you get the idea.
I'd love to have a Carbon MacPerl, and if someone goes through the trouble,
I would think it would be best to, at the very least, keep macperl-porters
abreast of what is going on, and make the source as clean as possible so it
can be used in a future version of MacPerl. Please do join macperl-porters
(http://lists.perl.org/) if you want to move forward with this. However, I
would first try to find out exactly what the problem is that you're seeing,
to make sure you really do need it Carbonized.
--
Chris Nandor [EMAIL PROTECTED] http://pudge.net/
Open Source Development Network [EMAIL PROTECTED] http://osdn.com/
