Most of this document was kindly donated by Bob Halpin, other (occasionally more sarcastic) annotations were made by me (Vince Darley).
LV: Oct 23, 2000
I notice TEA is another page on which someone describes their efforts in using TEA.
Vince: 1st Nov 2000, that page was put up there by me as well as this one. This page really contains many examples of the kind of hassle you can get into just getting TEA up and running at all. The other page contains both such stuff and a million more problems which arise when you try to use TEA for yourself (i.e. to do some real work like compiling your own extensions).
LV: In both cases, it appears to me that the descriptions are of attempting to build TEA enabled extensions on the Windows platform, primarily. And I know that there are significant barriers to building them on MacOS (pre MacOS X anyways). What other platforms face such barriers? What developers using these platforms have submitted suggested cross-platform solutions to the TEA mailing list?
Vince: 1st Nov 2000,
point 1: This page is 'windows only'; the other page contains problems on both windows and linux. This is one aspect of TEA that surprised me: I thought once my code was configured, compiled, installed, tested on Windows that I would then be able to pass it over to linux and './configure ; make ; make install ; test' would work. Silly me. There are lots of bugs in TEA which prevent that (see other page for details).
point 2: 'cross-platform' solutions? I know that someone (Chang Li?) has suggested his Xwizard as the basis of a cross-platform tool. I would suggest starting from scratch with something written in Tcl/Tk. To start with (on Unix) it could even use some of that autoconf/configure stuff as a helper, but the idea would be to evolve away from that. The major stumbling block with TEA is that very few people use it, apart from some unix gurus at ajuba, and that even fewer people can actually help to improve it (because it is an excessively complex 'unix system', I don't think it's worthwhile for windows developers to learn enough to be able to fix anything). This was (IMHO) the big error made at the TEA summit [L1 ] when the decision was made to go with a unix system. I don't know who will have the time/resources/dedication to set something up to find an acceptable solution, but TEA is not it. In many ways it is a sad reflection on Tcl that its core developer community chose a different scripting framework as a build system. But perhaps this leads to a gradual solution: since Tcl can glue nicely to all those nasty tools (autoconf/configure/make/...) we could base a build system off Tcl which starts as little more than a wrapper around those tools, and can then gradually (perhaps?) have pieces replaced by pure-Tcl in conjunction with some platform-specific data-files.
LV: Oct 25, 2000 I got a message from Jeffrey Hobbs with this URL for help for those trying to do this development:
http://www.hwaci.com/sw/mktclapp/win32-compile.html
Vince: so even Jeff Hobbs is pointing people to non-TEA resources for compiling!
Annotations are written like this, although the later ones need better Wiki formatting (how can I easily format multi-line annotations to look different?).
The most recent versions of Cygwin seem to have a smoother installation and a more pleasant directory structure. This also appears to mean that, for example, installing 'autoconf' does NOT require a --prefix, --exec-prefix set of flags (in fact using them seems to lead to all sorts of problems), and that issues with /tmp, /bin etc have disappeared. However there is a new installation option for default line-endings: DOS or Unix? I tried Unix, but then when I tried to run autoconf, I got an error than /usr.../m4 had no line-feed, so then I tried 'DOS', and that worked (or rather autoconf then worked -- no idea what problems may be lurking.). This new installation does make things easier, but makes about half of these wiki-TEA pages obsolete.
10 Steps to Success
This page describes how to get the TEA build environment working on Windows. This is probably the most controversial aspect of TEA: the use of autoconf, configure, and make to build things as opposed to using VC++ project files.
We feel your pain but not enough to fix any bugs in TEA for the last year or so, or to improve TEA to make it more palatable to Windows users
But, we also build all our software automatically, and you really can't automate the process without makefiles.
I thought Tcl itself was supposed to be rather good at automating processes. Silly me, I have deluded myself thinking I was actually automating anything. It just isn't possible without makefiles! Why use Tcl to build Tcl extensions when you could use something completely different with which half of your user/developer-base have no familiarity. Ok, to be more objective: you obviously need some sort of 'make-like-system', but there is no reason why that HAS to be make/configure/autoconf. Tcl would appear much better suited to the task. Given that 50% of Tcl users/developers appear to be on Windows, choosing a system which none of them can help to improve appears to be a very bad decision
For a general description of TEA and autoconf/configure/make, please see our Tcl Extension Architecture paper.
Note: This page lists a bunch of steps you take by running commands. These commands must be run in the bash shell. The first part of the process is installing the Cygwin tools that include this. Don't try these commands at a DOS prompt.
10 Steps to Success
1.Start by downloading the cygwin tools.
These are free, and you get them from an FTP site near you. There is a list of mirror sites on the
sourceware.cygnus.com Web site. The main site is ftp://sourceware.cygnus.com/pub/cygwin/, but this is
busy and a mirror may provide faster access. This directory has a link called latest, which at the
time of this writing goes to the b20 directory. There you should get the full installation (about
14 Meg), which is in a file called full.exe. Unfortunately, the "usertools" distribution (3 Meg)
doesn't come with make, sigh.
Full Cygwin Distribution (ftp://www.tcl.tk/)
Full Cygwin Distribution (sourceware.cygnus.com)
Did it, got: CygwinFullInstall20_1.exe 14,247,216 06/12/00 01:47p
2.Install the package by running the full.exe installer.
No such file as 'full.exe', so I guess I run CygwinFullInstall20_1.exe
This unpacks into a single folder that occupies a little under 40 Meg on your hard drive. I installed
mine on my D: drive under a cygnus folder. By the way, the installation includes a copy of Tk/Tcl
8.0, Tix 4.1, and [incr Tcl] 1.5.
OK, space consumed is 40,213,389 bytes.
(You might be able to delete the H-i586-cygwin32/i586-cygwin32 folder to save about 16 Megabytes of
space. This contains the compiler tools, which we don't actually use. Instead, we still use the VC++
compiler, but in the framework of other cygwin tools.)
3.Run the bash shell via the cygwin.bat script.
You can find cygwin.bat in the top-level directory of the cygwin installation. This batch file alters
the PATH and runs the bash shell. If you don't know about UNIX shells, they are command interpreters
like the "MS-DOS Prompt" tool available under windows. Essentially all the programs in the cygwin
toolset are simple command line utilities that are designed to run under the bash shell, either
interactively or in scripts. Yup, back to the good old days of command prompts and scripts.
Wrong. The installation 'top level directory' defaulted to c:\cygnus (which I changed to d:\cygnus) and all it contains is a directory called cygwin-b20 and THAT is where the cygnus.bat BAT is.
Also, point 5 discusses the Cygnus item added to the Start menu. Why isn't that point here?
OK, I'll just shut up and run the shell:
D:\cygnus\CYGWIN~1>cygnus
bash.exe: warning: could not find /tmp, please create!
bash-2.02$
Gee, no mention of /tmp in this doc. Hmmmm... guess I'd better create it. (So I do.)
4.Create a /bin directory.
Some tools, especially make, assume "/bin/sh" is available, so setting this up is crucial. The bin
directory is something like d:/cygnus/cygwin-b20/H-i586-cygwin32/bin, which in 8.3 format will
appear as d:/cygnus/CYGWIN~1/H-I586~1/bin. Note that you can use forward slashes in your file
names under bash, much like you can in Tcl scripts. Run the bash program as described above,
and utter the following command (suitably modified for your installation directory):
mount -f d:/cygnus/cygwin~1/H-i586~1/bin /bin
This will create a sort of symbolic link from /bin down into the installation that will persist
across reboots. It is only meaningful to bash; the MS-DOS programs won't see it. Alternatively,
you can create a C:/bin directory and copy the sh.exe program into it.
??? "4.Create a /bin directory." Do I 'mkdir /bin' as the instruction implies? Or, do I 'utter the following ... mount' command? Do I do both?
I try this: bash-2.02$ mkdir /bin mkdir: cannot make directory `/bin': File exists
Hmmmmmm... I figure this is because this is not a fresh Cygnus install. I uninstall Cygnus, reinstall it, and try again. Same result. I 'scrub' all my drives to remove any trace of Cygnus and still I get "File exists". I try a fresh install on a different NT machine and the mkdir /bin completes without complaint. I grow meditative...
Maybe I should try to 'utter' the mount command:
bash-2.02$ mount -f d:/cygnus/cygwin~1/H-i586~1/bin /bin
mount failed: Device or resource busy
Ouch. Maybe the full path will work:
bash-2.02$ mount -f d:/cygnus/cygwin-b20/H-i586-cygwin32/bin /bin
mount failed: Device or resource busy
(%$@*#!$%#&*) I wonder if anything works?
bash-2.02$ mount -f d:/ThisIsDrivingMeNuts/bin /bin
mount failed: Device or resource busy
Nope, I guess not. I wonder what IS mounted?
bash-2.02$ mount
Device Directory Type Flags
d:\cygnus\cygwin-b20\H-i586-cygwin32\bin /bin native text!=binaryGosh, that is a persistent symbolic link! It persists even through several uninstalls!! Smells to me like another piece of 'lint' in my registry that the uninstall leaves behind. Yup, there it is: HKEY_CURRENT_USER|Software|Cygnus Solutions|CYGWIN.DLL setup|b15.0|mounts|00 Now, let's test this by uninstalling Cygnus. Done, and the uninstaller say's that the program registry keys have been removed (what a good boy!) I run regedit and the whole damn Cygnus tree is still there. So disappointing, I thought stuff from the unix world was better behaved and less sloppy than this. Wrong again. (I reinstall Cygnus (again))
5.Set up your PATH so the Cynwin tools are available.
Because nothing is installed into the shared windows folder, you must update your PATH explicitly.
If you don't mind always running the cygwin.bat file, then that already takes care of it for you.
The installer puts this into your Start menu for you, and you could create a shortcut to that batch
file on your desktop. You can also alter your system environment settings via the Window control
path to put the right directory into your PATH.
First of all, this should have been point #3 ("Run the bash shell...") Second, that's 'cygwin' not 'cynwin' Third, (as point #3) it should be something like:
3.Run the bash shell.
During installation, a program group called "Cygnus Solutions" is added to the Programs
list on your Start menu. The group contains one item: "Cygwin B20", which invokes the
'cygnus.bat' file found in the \cygnus\cygwin-b20 directory. The batch file sets the necessary
environment variables and runs the bash shell (bash.exe.)
You can run the shell through the Start menu, or by running this batch file.
instance), you must first add the system environment settings contained in cygnus.bat
to Settings|Control Panel|System|Environment. Examine the cygnus.bat file for the items to
add.
6.Download autoconf.
Autoconf is the program that converts configure.in files into configure scripts. In many cases the
CVS repository will only contain configure.in and you must generate configure using autoconf.
Unfortunately, the autoconf script is not part of the cygwin tools. You can download it from
ftp.gnu.org. You'll probably need to use one of the mirror sites. Or, simply use this local copy
from our FTP site:
autoconf-2.13.tar.gz
Done. File is 443,844 bytes
7.Install autoconf.
You'll use configure and make to install autoconf. Unpack the .tar.gz file (WinZip can handle this format).The above two sentences should be in reverse order, or the first sentence should be deleted.
Now, run bash and execute the following commands to configure and install autoconf.
cd d:/autoconf-2.13
sh configure --prefix=d:/cygnus/cygwin-b20 --exec-prefix=d:/cygnus/cygwin-b20/H-i586-cygwin32
make
make install
The --prefix and --exec-prefix flags correspond to the Cygwin installation directory structure.
If you leave out the --prefix, the default value is c:/usr/local, and --exec-prefix defaults to
--prefix. The --prefix and --exec-prefix flag are explained in more detail in the TEA document.
You'll see this sequence of configure and make more when we build Tcl, Tk, and some extensions.
All seems to go well (at least no obvious smell of burning...)
8.Build Tcl
If you build from the CVS repository, you must start by running autoconf to create the configure
script.
cd d:/tcl8.3/win
autoconf
If you start from a Tcl source distribution from the FTP site, then this step has already been done.
(We are still debating whether or not to put the configure file into CVS...) Now create a directory
to build in, and configure the Makefile there, and run make to build Tcl
mkdir debug
cd debug
../configure --enable-symbols
make
make test
make install
I start with a Tcl source distribution from the FTP site (since we can't do CVS through our firewall.) so I:
bash-2.02$ cd d:/Tcltk830/tcl8.3.0/win bash-2.02$ mkdir debug bash-2.02$ cd debug bash-2.02$ ../configure --enable-symbols creating cache ./config.cache checking whether make sets ${MAKE}... yes checking for Cygwin environment... no checking for object suffix... obj checking for mingw32 environment... no checking for executable suffix... .exe checking for building with threads... no (default) checking how to build libraries... shared checking compiler flags... using shared flags checking for build with symbols... yes checking how to run the C preprocessor... cl -nologo -E checking for errno.h... yes updating cache ./config.cache creating ./config.status creating Makefile creating tclConfig.sh creating tcl.hpj sed: can't read ../tcl.hpj.in: No such file or directory
Now what!? Can't find tcl.hpj.in eh? Maybe I can. Yup, it's in D:\TCLTK830\tcl8.3.0\tools. So, do I copy it to D:\TCLTK830\tcl8.3.0\win, or do I hunt for a reference to it in some nutty .in file or something and change the path...? Who the heck knows. (Now I'm wondering how they "...build all our software automatically...")
I'll try copying it:
bash-2.02$ cp ../../tools/tcl.hpj.in .. bash-2.02$ ../configure --enable-symbols loading cache ./config.cache checking whether make sets ${MAKE}... (cached) yes checking for Cygwin environment... (cached) no checking for object suffix... (cached) obj checking for mingw32 environment... (cached) no checking for executable suffix... (cached) .exe checking for building with threads... no (default) checking how to build libraries... shared checking compiler flags... using shared flags checking for build with symbols... yes checking how to run the C preprocessor... (cached) cl -nologo -E checking for errno.h... (cached) yes creating ./config.status creating Makefile creating tclConfig.sh creating tcl.hpj
I'm a freakin genius. On with the show:
bash-2.02$ make <<yada yada yada>>
Several minutes later it looks like I've got a shiny new tclsh83d.exe. It runs! (This confirms my basic philosophy with computers: Sometimes things work.) ''
9.Build an Extension
Gee, if I can build tcl, this should be a snap! (Pride goeth before a fall.)
If you build from the CVS repository, you must start by running autoconf to create the configure
script.
cd d:/thread1.0/
autoconf
Is there an 'else' missing here, or just and 'endif'?
TEA extensions have their configure and Makefile at the top of their directory structure. These files are
shared by UNIX and Windows builds. Run autoconf in the top directory.
Create a build directory such as unix/solaris or win/debug. Change to that directory and run the configure
script to generate your platform-specific Makefile. The --with-tcl flag is used to specify the directory in
which Tcl was built.
mkdir win/debug
cd win/debug
d:/thread1.0/configure --enable-symbols --with-tcl=d:/tcl8.3/win/debug
make
make test
make install
'' I download ftp://www.tcl.tk/pub/tcl/examples/tea/smpext02.zip and unzip it. Then:
bash-2.02$ cd d:/sampleextension-0.2 bash-2.02$ mkdir win/debug mkdir: cannot make directory `win/debug': No such file or directory duh, that's what the instructions say to do bash-2.02$ mkdir win bash-2.02$ mkdir win/debug bash-2.02$ cd win/debug bash-2.02$ d:/sampleextension-0.2/configure --enable-symbols --with-tcl=d:/Tcltk830/tcl8.3.0/win/debug creating cache ./config.cache checking for gcc... cl checking whether the C compiler (cl ) works... yes checking whether the C compiler (cl ) is a cross-compiler... no checking whether we are using GNU C... no checking whether cl accepts -g... no checking for a BSD compatible install... //d/cygnus/CYGWIN~1/H-I586~1/bin/install -c checking whether make sets ${MAKE}... yes checking for ranlib... ranlib checking for Cygwin environment... no checking for object suffix... obj checking for mingw32 environment... no checking for executable suffix... .exe checking for Tcl public headers... configure: error: tcl.h not found. \
Please specify its location with --with-tclinclude
Oh oh. Better read #10 - Common problems. No help. I guess this never happened to anybody before. OK, where is tcl.h? It's in D:\TclTk831\tcl8.3.0\generic. So:
bash-2.02$ d:/sampleextension-0.2/configure --enable-symbols --with-tcl=d:/Tcltk830/tcl8.3.0/win/debug \
--with-tclinclude=d:/Tcltk830/tcl8.3.0/generic
loading cache ./config.cache checking for gcc... (cached) cl checking whether the C compiler (cl ) works... yes checking whether the C compiler (cl ) is a cross-compiler... no checking whether we are using GNU C... (cached) no checking whether cl accepts -g... (cached) no checking for a BSD compatible install... (cached) //d/cygnus/CYGWIN~1/H-I586~1/bin/install -c checking whether make sets ${MAKE}... (cached) yes checking for ranlib... (cached) ranlib checking for Cygwin environment... (cached) no checking for object suffix... (cached) obj checking for mingw32 environment... (cached) no checking for executable suffix... (cached) .exe checking for Tcl public headers... d:/Tcltk830/tcl8.3.0/generic checking for Tcl configuration... (cached) found //d/Tcltk830/tcl8.3.0/win/debug/tclConfig.sh checking for existence of //d/Tcltk830/tcl8.3.0/win/debug/tclConfig.sh... loading checking for building with threads... no (default) checking how to build libraries... shared checking for build with symbols... yes checking for tclsh8.2.exe... (cached) /TCL820/bin/tclsh82.exe updating cache ./config.cache creating ./config.status creating Makefile sed: can't read d: No such file or directory sed: can't read d:/sampleextension-0.2//sampleextension-0.2/Makefile.in: No such file or directory creating mkIndex.tcl sed: can't read d: No such file or directory sed: can't read d:/sampleextension-0.2//sampleextension-0.2/mkIndex.tcl.in: No such file or directory bash-2.02$
(I'm starting to wonder: Did whoever wrote this document EVER test any of it?)
Onto the comp.lang.tcl newsgroup and post the problem. Reply (from [email protected]) say's that the --with-tcl items should use //d/ instead of d:/
(unlike this documentation)
Ok:
bash-2.02$ d:/sampleextension-0.2/configure --enable-symbols --with-tcl=//d/Tcltk830/tcl8.3.0/win/debug \
--with-tclinclude=//d/Tcltk830/tcl8.3.0/generic
<yada, yada, yada> checking for tclsh8.2.exe... (cached) /TCL820/bin/tclsh82.exe updating cache ./config.cache creating ./config.status creating Makefile sed: can't read d: No such file or directory sed: can't read d:/sampleextension-0.2//sampleextension-0.2/Makefile.in: No such file or directory creating mkIndex.tcl sed: can't read d: No such file or directory sed: can't read d:/sampleextension-0.2//sampleextension-0.2/mkIndex.tcl.in: No such file or directory bash-2.02$
Hhhhhhhmmmmmmmm... No change, but Vince sounds like he knows what he's doin. Maybe I need to use //d/ in the call to configure at the beginning as well.
Try:
bash-2.02$ //d/sampleextension-0.2/configure --enable-symbols --with-tcl=//d/Tcltk830/tcl8.3.0/win/debug \
--with-tclinclude=//d/Tcltk830/tcl8.3.0/generic
WOW! Configure completes! (Well, it ends without any error messages, but god forbid it would say anything like half friendly like 'success'.)
Now to try make:
bash-2.02$ make cd //d/sampleextension-0.2 && autoconf //d/cygnus/CYGWIN~1/H-I586~1/bin/autoconf: cannot create D:\Cygwin\/tmp/acout.2221: directory nonexistent make: *** [//d/sampleextension-0.2/configure] Error 2 bash-2.02$
(Now I know they never tested it.) Another post to comp.lang.tcl ... plus I'll sniff around as well.
Wait a minute - what's with the reference to D:\Cygwin??? Blimey! I had Cygwin installed once, but removed it. More registry haunting?
bash-2.02$ mkdir //d/Cygwin bash-2.02$ mkdir //d/Cygwin/tmp bash-2.02$ make <yada, yada, yada>
Creating library exampleA02d.lib and object exampleA02d.exp
: exampleA02d.dll If you have documentation to create, place the commands to build the docs in the 'doc:' target. For example:
xml2nroff exampleA.xml > exampleA.n xml2html exampleA.xml > exampleA.html bash-2.02$
We have lift-off! (But the crew died of old age.)
Hey Ajuba - can you feel my pain?
''
10.Common Problems
First, make sure you have Microsoft VC++ installed. In theory it will be possible to use gcc on
Windows, but the configure files to not check for gcc nor set the correct compiler flags.
If the configure step cannot find the compiler even though it is installed, then your PATH probably
does not include BIN directory of Developer Studio (e.g., d:/program files/Microsoft Visual
Studio/VC98/Bin). There are a few other environment variables you need, too. What I did was copy
the VCVARS32.bat file into the CYGWIN.bat file so everything is set up when I run bash.
If "make test" generates lots of errors, try running the test suite from a directory on the local hard
drive. Many of the file system tests do not work well with remote file systems.
If "make install" puts the files into the wrong locations, specify the --prefix and --exec-prefix configure
options to set those installation locations properly.