It is the stated goal of Nick Ing-Simmons to turn John Ousterhout's Tk
X-toolkit into ptk the portable X toolkit. From
the Tk-b11.01 README file:

pTk sub-directory is a modified version of Tk4.0p3
It has been modified to call "glue" functions rather than use libtcl.a - so it
is completely independant of TCL.
A goal is to have pTk directory and its library usable from
perl/Tcl/LISP/c++/python etc. - perl is 1st.
There are still serious snags with the others.

So the stated goal is to eventually port to other languages.

How about the more modest goal of porting the Tk extension to perl5
to the widest variety of platforms (other than Un*x)? That is the issue that
this document attempts to address. Please note that this document is a
collection of rumours and slightly out of date material - please exercise
extreme caution in the use of the information contained herein. For more
up-to-date information subscribe to the
ptk@lists.stanford.edu mailing
list, by sending the message:

X is covered by some sort of license. The phrase "X Window System" was
originally copywritten by the Massachusetts Institute of Technology. I don't know, but
perhaps the X Consortium has dibs on that phrase now.

Perl is copywritten by Larry Wall. Here I am reproducing a copywritten
statement from the Camel (pp 433):

Perl is copyrighted, and is thus not in the public domain -- it's just
freely available and freely redistributable (q.v.).

Perl is covered by a couple of licenses
(GPL and
Artistic). Here is the
README file that comes with
perl5.002. There is also the Artistic
file that comes with perl5.002. Anyone seriously considering working toward
the advancement of perl ought read those files carefully, very
carefully.

Copyright (c) 1995 Nick Ing-Simmons. All rights reserved.
This package is free software; you can redistribute it and/or
modify it under the same terms as Perl itself, with the exception
of the files in the pTk sub-directory which have separate terms
derived from those of the orignal Tk4.0 sources and/or Tix.
See pTk/license.terms for details of this Tk license,
and pTk/Tix.license for the Tix license.

The absolute minimum you need is a C language (or C++) compiler. It is
tremendously helpful to have a few other things as well.
The short list is: a C-compiler, Xlib, perl5, the Perl/Tk kit,
and a make utility (preferably one that is amenable to a MakeMaker
port to your system).

C language compiler

Has gcc been ported to your
platform? If so you are in luck as it is a C compiler most forgiving of coding
mistakes and/or "unconventionalities". However, it should be possible to port
perl and perl/Tk to any platform's C compiler.

Does your platform's C implementation (compiler & linker) support
dynamic linking? If so that would be a
plus, but it is not necessary. Having a C compiler (or a C++ compiler that can
reasonably handle C) is necessary. If all you have is a C++ compiler
that may be OK since a great many C++ compilers can pretend that they are C
compilers.

ANSI-ness is not as big a deal as you might imagine. If you wind up building
everything (including libX11 and perl) using your C compiler then everything
ought to work even if your compiler is not ANSI compliant.
It is a great idea (you _must_?) build Tk using the same compiler that you
used to build perl. If you are lucky enough to be able to use MakeMaker with
your perl then the correct C compiler will be invoked from the Makefile
when you type the make command.

Xlib

Recall that X started in about 1984 to be the platform independent
interface thingy. It is supposed to work everywhere - yes even on your
PC/AT, and even on your Mac (<- on the Mac X even works with DECnet
transport protocol [though tcp/ip is much more common]!).

The X Window System, or X, is a network-transparent window system...that was
designed at MIT.
...
It runs under ... several operating sytems.
...
Xlib is a C subroutine library that applications programs (clients) use to
interface with the window system by means of a stream connection.

Please note that while much X documentation refers to "X toolkits" (e.g.Xt, Xm, Xmu, etc.) such toolkits are typically
front ends to C subroutine libraries. Hence those "toolkits" are typically
called from some other compiled language (which is usually C or C++). Tcl/Tk
and Perl/Tk are a bit more than mere "toolkits" in that they allow access to a
good deal of Xlib functionality via the other languages (Tcl and Perl
respectively). [BTW there also is a Lisp version of Xlib that you need not
concern yourself with in an attemp to port Perl/Tk.]

Perl/Tk can be built on Unix platforms under X11 R5, R6, and R6.1. I do not
know if it has been built with prior releases.

The critical Xlib files include: the sharable image libX11.a (or
libX11.so, or LIBX11.EXE, or whatever
name.extension your system uses for this type of file), and the header file
Xlib.h (as in #include <Xlib.h>).

Perl 5

You want the object oriented perl5 - the fresher the better (by that I mean
try to get a very recent version). Perl 4 just will
not cut it. Find a CPAN ftp site near you.

A "make" utility

On Unix platforms the standard make utility uses a Bourne shell type
syntax for carrying out compiling and linking of (usually complicated) source
code. There is also a GNU make utility called gmake - has it been
ported to your platform? Does your C compiler have "project files"? (These are
equivalent to Makefiles.)

On VMS there is a commonly used MMK utility that uses a DCL shell syntax.

I would presume that a MacMaker could use AppleScript(?), a DOS|WIN|OS/2
maker would use a CMD *.BAT file (or Rexx?), etc..
On the microcomputers there are also commercial C compiler IDE's that do the
equivalent of make with .c and .h code typically using "project files".
(You might want to disentangle yourself from the non-transportability
and awful licensing issues involved with these IDE's though.)

How good is your platforms' port of perl5? MakeMaker? Basically will:

perl Makefile.PL

"work" on your platform (i.e. create the right type of Makefile [or
equivalent])? This question involves the platform specificity of the
Extutils::MakeMaker module. Note that there are MM_Unix.pm,
MM_OS2.pm, and MM_VMS.pm modules to help on those platforms.
To help develop MM_foo.pm on your Foonix platform, consider
subscribing to the MakeMaker mailing list
makemaker@franz.ww.tu-berlin.de.

Can your platforms' perl port turn .xs into .c and .h? In other words
is your h2xs and xsubpp working? Either of these perl utilites
may require some modification for use on your system.
With modern perl's one can make very effective use of statements like the
following within the perl code:

use Config;
if $Config{osname} eq 'VMS' {
# VMS stuff goes here
}

Your perl5 Autoload utility should be working too (if your C compiler
does dynamic linking).
How about
ExtUtils::Mkbootstrap?

Perl/Tk kit

Pick up a version that corresponds to the version of perl you will be using.
Failing that pick up the
latest release. Either should be available on CPAN.

other things

Has Tcl/Tk been ported to your
platform? If so you might consider looking
through the relevant READMEs and/or Makefiles for that software package as
a guide to understanding how to port Perl/Tk to your system. (Hint: you want to
try to compile it on your machine. In other words,
do not simply pkunzip a WISH.EXE file.)

How about the xmkmf program or the
patch program? They would be
useful (but are not necessary).
The previously mentioned gmake program
would be useful on any system. It may have been ported to yours.

Of course dealing with file distribution can be a portability problem in its
own right. Perl code is typically distributed from CPAN sites via binary mode
ftp of *.tar.gz files. Hence you need: ftp, tar, and
gunzip. Note that the
gunzip program is different from unzip and different from pkunzip.

But of course, some ports do lose (or gain) a little in the translation. On systems
whose C-compiler only supports static linking making the static version
(perhaps via "make tkperl" after "make" and before
"make test") would be great too.

The first of these build steps (perl Makefile.PL) is the MakeMaker step
and strictly speaking is not necessary if you can figure out an alternative
means of quickly putting together a Makefile (or project file, or
whatever) for not only this version of Perl/Tk but all
subsequent versions. (In other words hacking away with a text editor
to come up with a Makefile for Tk-versionX to compile means that anyone making
use of your port of Perl/Tk will be stuck with -versionX, meanwhile everyone
else will have moved on to -versionX+1). On Unix systems
the Makefile.PL script that comes with the Tk module calls the
myConfig perl script to query the computer (actually the
xmkmf program) about where it's Xlib libraries and headers are. So
where on your system is libX11.a (or
libX11.so, whatever)? Where on your system is the
Xlib.h file? These are the types of questions that need answering
when trying to compile the Tk extension to perl on your system.

The second of these build steps (make) is the compile, archive/library
objects, and link step and must of course be translated into your platforms'
C-compiler-and-linker's native format. As hinted there is an optional
make tkperl step for statically linked compiler/linkers [of course
this target may or may not be in your Makefile depending on whether you
have a Makefile].

The third step (make test) really only runs the widget
demo script to make sure nothing has gone wrong. On Unix systems the
Makefile is set up with dependancies such that typing
make test will do a complete make if it had not already
been done. On a port to a system much different from Unix it would not be at
all unreasonable to ask people to simply run the widget demo using
perl in whatever fashion it is invoked on your system.
On Unix the make install step copies the code over to a special perl
installlation directory. This step may be unnecessary on your system.
In sum: the make step of compiling (cc) object collection (ar)
and linking (ld) is most critical [so tricky in fact that that is why the
make program was invented!], the first step is simply an automatic way
to get perl to set up the Makefile for you (and probably should not
be overlooked by you).

You can of course read a detailed description of how to build Unix Perl/Tk in
the appropriate entry in the Perl/Tk FAQ.

Nick Ing-Simmons has
outlined
the steps necessary to port perl/Tk to other (non-unix) platforms:

Re: Perl/Tk for NT

Nick Ing-Simmons (nik@tiuk.ti.com)Fri, 12 Jan 96 08:54:30 GMT

In <30F594C8.5798@dsto.defence.gov.au>
On Fri, 12 Jan 1996 09:22:56 +1030
Matthew Phillips <mathew.phillips@dsto.defence.gov.au> writes:>Hi,>>I'm very impressed with your Perl/Tk package and am hoping to be able to>use it for the GUI implementation of our next project. However, we need>to be able to run on Windows NT primarily, and UNIX (Solaris) at a later>date. I know there is an NT Tcl/Tk port, but what are the odds of a>Perl/Tk port? If there isn't one, how difficult would it be for a>reasonably experienced UNIX hacker to convert the NT Tk package to be>usable via Perl 5?>>Keep up the good work!>
As far as work time goes I can justify (some) time spent on UNIX
perl/Tk. An NT (Win32) port would have to be a home (hobby) project,
and I don't have (or particularly want) an Win32 machine at home.
(My home machine is a dual CPU SPARCStation10,Solaris2.4.)

What 'we' need is a "reasonably experienced _NT_ hacker":

What I need is someone that understands Win32 (or OS/2 as may be),
to figure out issues like DLL/OLE (which is just an acronym to me).
I could learn this stuff of course - guess I will some day - but don't
have the time to learn it now. Anyone who knows they need the port
knows more than I do in this area.

The steps are :

1. Build Perl for your environment - I think you need to re-compile
from sources. This may be ntperl or via gcc-win32 or however.

2. Work with me/porters to incorporate a "trivial" C extension to this perl,
to see what is involved - we can do this 'static linked' if this
helps.

3. Build John Ousterhout's Tcl/Tk4.1a* for your environment, so that we
understand what it can do and bits that need to be there.

4. I apply my tk4.0 vs perl/Tk diffs
to 4.1a and run all the C files though my munging perl scripts.
I then have a UNIX 4.1a - my guess it might take a day or two.

5. Do same things as (4) to bits of 4.1a that UNIX does not use, based on
understanding developed in (3).

6. Then compile all those, iterate munging/compile as required.

7. Apply the "how do we add a C extension" lessons from (2) to objects
from (6) to get perl/Tk executable(s).

8. Sort out inevitable filename/UNIXisms issues in *.pm files.

I can do (4) almost anytime. But there is little point unless someone
is going to use it soon as otherwise it will have to all be done again
if a new Tk4.* comes out...

Well that is what Nick had to say about WinNT|Win32|OS/2 in particular - but
of course the methods described are equally applicable to any
other platform.

For help in understanding what is involved in Nick's step number 2 above consider
working through the example given in the
perlxstut
man page (as well as
perlxs(1)
and the pod docs for
MakeMaker.)

In step number 4 Nick is referring to the Unix diff program that
tells you the difference between two files (usually text files). The output of
diff are the "diff files" that Nick is referring to. The inverse of
the diff program is Larry Wall's patch program (which is also
distributed separately as a GNU utility - unfortunately not as a perl script!).
Do you have a patch program on your system that would allow you to
apply Nick's diff files? If you do not then you will need to do a lot of hand
editing (it is possible to simply read diff files - they are plaintext).

Note that on the perl Makefile.PL step (under Unix) it is sometimes
necessary to give explicit locations of the required X11 libraries and/or
include headers. For example, if libraries and headers are in one location
(that the xmkmf program cannot find) then:

perl Makefile.PL X11=/usr/local/X11R6

or, if the headers are in one place and the sharable libraries are in another
place then:

Herein follows a discussion of a simple C program that uses X and contrasts
it with an equivalent simple perl script, a simple wish script, and a simple
perl xs subroutine. Following any or all of these steps ought to help you
uncover problem areas for compiling perl/tk on your system. The discussion of
the xs extension might also help folks who wish to write their own widgets.

Lesson 0: hiworld.c
In an effort to test your ability to port and use Xlib on your platform consider writing
and compiling a very simple C program that uses Xlib. For example
hiworld.c. On a typical UNIX computer
I can compile and link that program with a command like:

cc hiworld.c -lX11

whereas if I used the GNU C compiler that would simply be:

gcc hiworld.c -lX11

(and you may need other -l or -L arguments depending on the details
of your system.)

(Note the tcl/tk version is only 6 lines!,
neither of which is really fair to the C version since it cannot even refresh
the additional "Hi." strings on expose events the way the
perl and wish scripts do automatically.)

Lesson 1: Makefile
Assuming you are able to figure out how to compile and link
hiworld.c, an additional step to
take would be to try coming up with a Makefile for it (although this
would not be necessary if you have MakeMaker and can follow the
steps in Lesson 2 below). The crude way to create a Makefile
is to simply use a text editor to write something like this:

hiworld : hiworld.c
cc -o hiworld hiworld.c -lX11

which would be invoked with "make hiworld" for example. It is considered
much more fashionable to throw in a bunch of macros into one's
Makefile's as in the following:

which is still invoked via "make hiworld" even though it looks a little
more complicated.

Lesson 2: h2xs, xsubpp, hiworld.xs, Makefile.PL
The point of this exercise is not to show how to "add X routines to perl" (even
though that is what it does). The point is to illustrate the use of
h2xs, xsubpp, ExtUtils::MakeMaker, et al. Please note
that each of these useful perl utilities may or may not have been ported to your
system. If not then see if you can lend a hand in doing the port.

Following the perlxstut(1)
man page we go to an otherwise unused directory and type:

h2xs -A -n Howdy

and note the creation of a new Howdy directory with four new
files: Howdy.xs,
Howdy.pm,
Makefile.PL,
and MANIFEST (with later versions
of h2xs there will also be a test.pl and a Changes
file).

To get our Xlib code into Howdy we
will need to append (and slightly modify) the contents of
hiworld.c to
Howdy.xs (on Unix that would be
something like cat hiworld.c >> Howdy.xs.) We edit Howdy.xs to
add the required CODE: and OUTPUT: RETVAL statements, as
well as to change function main(argv argc) to a funtion
hiworld(argv argc) (clever name eh?). So that now the head of Howdy.xs
appears as:

(note the function type of int, although void would have been
just as appropriate.)
The tail of Howdy.xs now appears as:

XCloseDisplay(mydisplay);
OUTPUT:
RETVAL

(note the absence of a call to exit(0);, and an absence of the
braces {} for main.)

We turn our attention to the Howdy/Makefile.PL file and change
the line that says:

'LIBS' => [''], # e.g., '-lm'

to read something like what we needed to use to compile hiworld.c from the
command line, like:

'LIBS' => ['-lX11'], # e.g., '-lm'

We can now say

perl Makefile.PL
make
make install

(note that after make and before make install you may be
able to make test if you have updated test.pl. Also, statically linked
Howdy perl binaries can be made by running:

make -f Makefile.aperl inst_perl MAP_TARGET=perl

after make and before make test.)
After make install it is possible to run perl scripts that call the
hiworld() subroutine in as little as three simple lines of perl:

#!/usr/bin/perl
use Howdy;
$return = &Howdy::hiworld($a, $b);

That is all there is to it! For illustrative and testing purposes I have made a
distribution copy of the
Howdy "module" for perl.
[Please also note that a much more extensive discussion of such an extension
as a Tk widget building exercise is taking shape as
this document.]

You may experience tremendous difficulty in getting any of the above steps to
work (they work pretty smoothly on most Unices). Hopefully, by following these
steps you will encounter the problem areas that need work on your platform's
port of perl. Do not be discouraged - ask around for help.

Of course it should not ultimately be necessary for you to use these
techniques (h2xs et al.) in a "standard compile" of Perl/Tk on your
system because Nick Ing-Simmons has already packaged everything for you.
Trying this test out as a means of uncovering what could possibly cause
trouble on linking Xlib calls to your perl ought to help with the port of
Perl/Tk to your system however.

Lesson 3: Tk's Makefile.PL
The Makefile.PL that is distributed with Tk is considerably more
complicated than the trivial one that we just made for Howdy in lesson 2.
Among other things the Makefile.PL with Tk calls external perl scripts that
try to call
the xmkmf utility on your system. Note that if your system does not
have xmkmf you may need to tell perl just where the Xlib stuff is
sitting on your system. This is why it is sometimes necessary to say something
like:

perl Makefile.PL X11=/usr/local/X11R6

or, if the headers are in one place and the sharable libraries are in another
place then:

(Another reason that specifying any of the X11 macros may be necessary
is to force a choice of one version of X11 over the default that gets specified
by xmkmf X11R6 over X11R5 for example.)

The statement within the main Tk Makefile.PL:

require "./myConfig";

invokes the myConfig script for snooping out X on your system.
Note also that in the Tk*/config directory there are a number of
tiny C programs for testing platform dependent things like: signed vs unsigned
char's and TIMEOFDAY_NO_TZ.

Tk's Makefile.PL also makes use of the Tk*/Tk/MM*.pm packages for
help in making the multiple Makefiles necessary for the complete build.

If you wish to discuss your Tk build problems with others run and save the
output from the myConfig script in the Tk build directory
(the output may already be in the myConfig.out file from your
Tk-b# build directory), as well as the myconfig script in your
perl build directory. It is often helpful to include the output of either
(or both) of these scripts in your discussion.

Presented here are the beginnings of a list of problems*
associated with
building Tk-b# on various operating systems.
Note that a working definition of "UNIX" would probably have to mention
something like:

That form of computer operating system which has proven so wildly
popular that one (or more) organization(s) has (have) attempted to either
sue or demand payment from one (or more) other organization(s) over the use
of the word "UNIX".

(* & successes are marked with an icon - meaning one or more versions of
Perl/Tk has been reported to run on the named OS. Conversely, the absence of an
icon cannot be construed to mean that Perl/Tk does not run there. The abscence
of an icon may merely mean that I missed the announcement of the successful
build [if such an announcement was made] :-)

John C. Wingenbach indicates that should you encounter an error message
like Cannot find -lX11 anywhere at ./myConfig line 184 when running
your perl Makefile.PL (under Slakware 3.0) that you should be
more specific about -l/path/to/libX11.a.
Adam Wasserman <awasser@hermes.sgc.com> has graciously provided a
compilation of Linux compilation trials & tribulations. It is an (as yet
un-edited) document available at:
http://w4.lns.cornell.edu/~pvhp/ptk/etc/linux_compile_compilation.txt

In private communication with Richard Stallman the previous ban on GNU work
for the MacPlatform has now been lifted (presumably because of competition it
is no longer a closed, proprietary computer platform). However, regarding a
port of the latest gcc to the Mac: "we have more urgent priorities".

Mark Pease <pease@act.sps.mot.com>
[Co-Author (with Carl Dichter) of Software Engineering with Perl]
reports that on his Mac IIcx running Tenon's MachTen 2.2 (BSD 4.3) with a
Mach kernel running on top of the Mac OS - it takes 3 hours
to compile perl and an additional 5 hours to compile the Tk extension.
He managed with Tk-b9.01 using Tenon's X11R5 version 3.1. (Strictly
speaking Mark considers this MachTen to be Unix.)

As of perl5.002b & Tk-b9.01 you will probably be able to follow the
usual instructions. John Stoffel <john@wpi.edu> reports that if you use
gcc (rather than cc) you should use at least version 2.7.2

For Tk-b8: make is reputedly not up to the task on this system.
Tk-b8/README.OSF recommends gmake instead.
Stephane Bortzmeyer
<bortzmeyer@pasteur.fr>
reports a successful build with Perl 5.001m, xsubpp 1.922,
MakeMaker 4.23. He points out that it was necessary for him to
upgrade the xsubpp and MakeMaker that he received with his copy of
Perl5.001m.

.

qnx:

Perl 5.002 definitely runs on this system.

.

SCO:

For Tk-b8: Eric J. Bohm
<bohm@cs.Buffalo.EDU>
reported a need to
comment out line(s) from myConfig and GNUMakefiles using
GNU make 3.67. (See Tk-b8/README.SCO for specifics.)

.

SGI (Irix):

Matthew Black
<black@csulb.edu> recently
mentioned a need to apply "patchSG0000596" to get perl sockets
to work. His message was copywritten and is not included here. Send
e-mail to him
to find out where the get "patchSG0000596".

.

Suns:

SunOS (BSD):
For Tk-b10 on SunOS 4.1.3_U1
using SparcWorks acc 3.0.1 Frederick L. Wagner <derf@ti.com> reports
needing to use the perl malloc rather than the system malloc() when building
perl.
For Tk-b8:
Tom Tignor <tpt2@BBN.COM> reports the
following on SunOS (sun4m sparc):
Tue, 28 Nov 1995 13:19:42
In trying to make, I got a "write: argument mismatch" error
for the file ptK/Lang.h. I looked at the file and found the offending
function, Tcl_GetOpenFile, which has a third argument called "doWrite"
(not "write") in tkGlue.c. I changed the argument from "write" to
"doWrite" in Lang.h and it's compiling fine (for the moment. :)
Solaris (System V):
For Tk-b8:
There is trouble getting perl to use Socket routines
(i.e. trouble with make perl itself not necessarily
trouble with Tk-b#). See the perl FAQ for more
info or the .shar file that
Tom Christiansen occasionally
posts to comp.lang.perl.misc.
Further information on perl inter process
communication can be found in the perlipc* files at:
ftp://ftp.perl.com/perl/info/everything_to_know/.

.

SVR4:

For Tk-b8:
Martha G. Armour and Len Reed report on two separate hardware platforms
running SVR4 - extensive details in Tk-b8/README.SVR4.
Interestingly, they report no trouble at all on Linux.

SVR5:

.

Ultrix:

Peter Prymmer reports that with Tk-b11 it was necessary to change the line in
Makefile.PL that reads:'LIBS' => ["$xlib -lX11 -lpt -lsocket -lnsl -lm"],
to read:'LIBS' => ["$xlib -lX11 -lpt -lsocket -lnsl -lm -ldnet"],
because of a newer X11 in /usr/local that needed the DECnet protocol linking.

John Stoffel reports a successful build of static Tk-b10 on Ultrix 4.5.

Charles Bailey <bailey@genetics.upenn.edu>
has done a wonderful job porting perl5 to VMS. It can be built using MMS,
MMK, or
VMS GMake or
IMake.
Not (yet?!) distributed on CPAN it is available from:
ftp://genetics.upenn.edu/perl5/perl5_vmstest.zip (Recommendations:
do not try anything but a VMS web browser to follow the hyperlink as
browsers on other OSes do not grok the
protocol on VMS ftp servers too well. If you do not have a VMS web-browser
then use line mode
ftp instead. Do use an
UNZIP
specifically compiled for the VMS file system.)

Gary Ng <garyn@winclient.com>
is currently working on an NT port of perl5.002. For a C compiler he uses
VC++ 4.0, but adds that there is a RSXNT which allows you to run emx port
of gcc (2.7.2). "It is great for porting unix utilities."

There are a number of commercial vendors of X code that tout
"platform independence" more strongly than does the
X consortium itself among them these organizations
that typically offer Xlib for sale (usually to microcomputer users) [some have
free demo versions available]: