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

Re: [MacPerl] We need more evangelism...




Georg Bauer wrote:

> In article <v03102812b1d6c47c4273@mac2.cfcl.com>, vlb@cfcl.com (Vicki
> Brown) wrote:
> 
> >it would never have occurred to me that Perl would have a reasonable
> chance
> >of building out of the box for an Amiga.  Or DOS.  Or Windows, or VMS.
> None
> >of which are Unix.
> 
> Sure it does. Amiga reproduces a quite useable Posix environment. On
> Windows, you use GNU-win32, a "Unix-emulation". DOS uses DJGPP. VMS is a
> known constant in the porting area. The Mac really is a problematic
> platform in those regards, as it's posix support is far from complete.
> 
> From all weird systems, the Mac is one of the weirdest - at least if you
> do porting work from Unix to the Mac. Actually I have high respect for
> Matthias for doing his work on MacPerl.
> 
> bye, Georg
> 
> PS: As a side note, there is _one_ platform in there that is a surprise
> for me: DOS. Up until now there was no official DOS port, only the OS/2
> port that was useable for DOS, too (and a hacked port based on Borlands C
> compiler). The move to directly support DOS in the core makes me quite
> happy, as one of my production systems still runs that beast. And a more
> featurefull implementation will make me even more happy :-)

The VMS port was not trivial: it does not use a Boune-like shell, nor any
GNU tools.  In fact the 5.002 release did not fully support MakeMaker and the
5.003 release did not build on VMS (5.003_07 did).

You have not been following the DOS port too well.  There was a README.dos
file in the source of perl 4.036 (oldest I have on hand - but I am pretty 
sure that the dos port precedes that), 5.000 Alpha 12 h
and I think the widely populer 5.001m.  Those older efforts were based mostly
on Commercial compilers such as Inprise's (then known as Borland).  The
recent work of Laszlo Molnar on the dos-djgpp port makes *extensive* use
of many gjgpp tools including a bash.exe port of the GNU bash shell to run 
Configure which then prepares the build for GNU make.  Were it not for the
GNU utilities on DOS that would not be such a slick port.

You can currently build and/or run perl for Win NT under any of the 
following ports:

 - Activestate (formerly Activeware formerly Hip Communications) - 
        includes ISAPI stuff and PerlScript (not released in source code)
 - MKS tools - perl 5 comes with the MKS toolkit for around US$500.00
 - "Standard" - the current beta releases of 5.005 build under any of:
   o MSVC++ 5
   o Inprise (formerly Borland) C++ builder
   o Mingwin32 - a collection of GNU utilities
   o uwin32 - a different collection of GNU utilities
   o OpenNT - a more fully implemented version of the POSIX standard for NT
 - OS/2 - yes it is possible to take the binary distrubtions for OS/2
          that Ilya Z. puts together and execute them on NT.  I've run
          print "hello world\n" on NT with "OS/2" perl binaries.  That is
          built on OS/2 under the EMX GNU environment for OS/2.

That is a total of 9 different ways to run perl on Win NT.  Some support
MakeMaker, not all of them support Win 95.  (I have not tried it but I suspect
that Laszlo's DOS port may work on NT too??? Of course I have not even 
mentioned the perl support on SCO, UNIXware, Linux, *BSD or any of the other
Intellish UNIX clones).  Confusion reigns there.  The Win32::* modules seem
quite handy but are very sloppily maintained - most do not have either pod
or regression test suites.

I like the idea of better integration of the MacPerl specifics into
the perl mainline.  If that necessitates a cleaner separation of the
IDE and resource handling, et alia into a separately downloadable source kit 
then so be it.  It might actually prove *easier* to maintain MacPerl that 
way since new minor subversions of the perl mainline could be released then 
dropped into an IDE kit that need only keep up with MacOS changes and 
minor bugfixes.

With such a change the familiar figure for layering your MacPerl installation 
might look like:
                         +---------------+
                         |    bigtool    |
 +---------+-------------+---------------+
 | bigappl | appl_cfm68K |      tool     |
 +---------+-------------+---------------+
 |              appl                     |
 +---------------------------------------+
 |         $CPAN/src/latest.tar.gz       |
 +---------------------------------------+
 |     MacPerl IDE && resource kit (src) |
 +---------------------------------------+
 |  CodeWarrior, MPW, GUSI, et al (?)    |
 +---------------------------------------+

I.e. to build the basic MacPerl app one needs a build environment,
the MacPerl specific stuff and then the standard distribution of perl
(there would of course continue to be a need for binary distributions).
Hopefully the need to update the bottom most layers would not occur
with great frequency.

The efforts to hook in more Mac-specific stuff are cool too.  Each major 
platform ought to boast its own little portion of CPAN.  The Mac is 
certainly a major platform.  There is currently more stuff in 
$CPAN/modules/by-module/Mac/ than there is in 
$CPAN/modules/by-module/VMS/.

I cannot say I would be too excited about using eight bit Mac-specific 
punctuation chars in any perl scripts.  Please understand that I have to
support EBCDIC platforms where the upper and lower case alphabets as well as 
all digits and quite a few common punctuation characters have the eighth bit 
set :-)

At this time the Mac (68040 and PPC) is the only platform that I have to 
worry about for which latest.tar.gz is irrelevant.  I would like to see that
changed.  How is the perl regression test suite doing on the Mac?

Peter Prymmer



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