@echo off set MSDEVDIR=%VCToolkitInstallDir% set INCLUDE=%MSSDK%\include;%VCToolkitInstallDir%\include set LIB=%MSSDK%\lib;%VCToolkitInstallDir%\lib set PATH=%MSSDK%\bin;%VCToolkitInstallDir%\bin;%PATH%Now you can build tcl using the <tcl>/win/makefile.vc NMAKE makefile. Or you could use Msys and CC=cl ./configureMichael Heca 2004-09-04: This binaries builded on Windows XP don't run Windows 98. There is no MSVCR71.DLL and is not installed by Tcl.AR It is likely to be an issue with manifest. Cf. my notes on it, and http://msdn.microsoft.com/fr-fr/library/ms235591.aspx
male - 25 May 2004: to download the Platform SDK (not to install) use http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm
CLN - 2005-01-29: Take care that there are two versions there: Windows Server2003 and XPSP2.APN 2010-05-19 If you do not need an IDE, the latest Windows SDK (Windows 7 version) also includes the Visual Studio 9.0 32- and 64-bit compilers.Michael Heca 2004-09-03: To compile help need file hcrtf.exe. Download it from ftp://ftp.microsoft.com/Softlib/MSLFiles/hcwsetup.exe
jcw - Would it be an idea to start using tclsh to streamline this sort of thing? I know that using tcl to build tcl sounds silly, but since we have several perfectly well-working binaries for Tcl on Windows, I think we can by now rely on it. The bootstrap issue is long behind us for Windows. So as addition to the above, it would now be quite feasible to create a Tcl script which does all of the above (even fetches things not yet present, if you really want to push it). This would make it possible to say to anyone:
To build the latest Tcl/Tk on Windows, get one script and tclkitsh or some such, and do <x>. Done. The script could be as straightforward or clever as we care to make it.I've used Tcl to drive the "genkit" build system, and have to admit that it really simplifies things, without having to make sure people have wget, a specific shell, etc. On Windows, it would be even more useful, to avoid getting a specific version of msys, or cygwin, and what have you not. In fact, it'd simply be a smaller download.So I guess the question is really a more general one: could this be a good time to start using Tcl for our own tasks some more?CL reacts: yes. It strikes me as a pure win. In particular, even if I'm stranded on, let's say, an embedded system which somehow lacks the Tcl I need to bootstrap, I assume I can move to some other host, and ask it (this contemplated Tcl-based generation system *will* have powerful introspection, no?) what I need to do on another system. This improves my life in every dimension when compared to reliance on *make.mjk: It would be a brilliant idea to use Tcl as a replacement for configure scripts and makefiles. I've been lately struggling with various makefiles, which were made for Visual C nmake utility and I have been converting makefiles for MinGW and Borland Make by hand (these were not related to Tcl/Tk in any way). This Tcl build-script idea would solve all dependencies on various compiler/system-specific tools if made right.I recommend using bras as a really powerful tcl-based build toolJH: I'm highly skeptical of using Tcl to build the Tcl core due to bootstrapping issues. I am highly in favor of relying on Tcl more for building Tcl extensions though (TEA or others).mjk: You are right about the bootstrapping. I forgot to think about that. I hate it when some Scheme or Common LISP implementation depends on older version of itself. But Tcl is (in my opinion) a bit different thing, because Tclkit is available for multiply platforms. Can't say same about other languages. But relying on the fact that Tclkit would be available for all platforms is a bit too optimistic and unrealistic thing to depend on fully. Anyway, using any autoconfig/automake scripts isn't good thing either for all platforms (I'm not going to use Cygwin or MSYS under Windows). Anyway, this page has inspired me to think about some sort of Tcl-based building tool which would be useful for my other projects (I'm aware of bras and aardvark).SRIV Its a heck of a lot easier to install a tclkit than any other build system on any platform. Boot strapping with a tclkit is trivial.jcw - It wasn't my intention to suggest "all" (or even "many") platforms. Just Windows - with all its msys/mingw/cygwin/msvc complexities. If we have Tcl, a pretty nifty pool of talented Tcl people, and a goal to deal with 1, then maybe even 2 or 3 compiler options on that platform, we could simplify. To the point where a Tcl script asks "do you want to fetch mingw and set it up?" or "update to latest Tcl sources and rebuild same as last time?". Similar to (and beyond) what genkit does for tclkit on Unix.I don't have strong feelings about this, nor any particular desire to see tclkit in that role - it's just that by now, the bootstrap issue on Windows (and Mac OS X, another single-binary base) is really no longer a constraint IMO. It doesn't have to be the most recent tcl/tk at all. Pick a solid 8.4 based one, declare its binary as frozen, available from multiple sources, 100% Tcl-compat OSS, and ... start imagining how much nicer life becomes for a Tcler to rely on top-notch scripting + GUI + networking infrastructure.If it were only about installing binary builds, one could argue for well-known installers, since that's what everyone does.But this is about source builds. In itself it seems like a useless idea - just ship that one last-release binary to everybody, right? But think about extensions, and how much more leverage Tcl could bring with an option to get a properly installed build system, ready for anyone to build and re-build tons of extensions. And... when repositories become a reality: submit those binaries back.So I think my argument boils down to: leverage. Giving anyone in the Tcl world on Windows the ability to keep extensions up to date, submit new ones, apply fixes, test on many Windows variants, etc. Tcl/Tk is a tool. The more widespread it works for people, the more it can drive development - some of it is inevitable going to come back as OSS, no?When in Rome, eh I mean on Windows ... make Tcl/Tk as convenient for developers as you can!SRIV Then perhaps a static tclsh/w libs, like freetclsh (from freewrap).
TV On the subject of how to build tcl from a free environment I think contributes well to developing reasonably under windows, cygwin, I make a page on Building Tcl under cygwin with MINGW .
2004-09-04 VI I'd recommend smake for tcl based makefiles. I am in no way related to the author (Thanks! Setok). But I've made minor modifications and think it's the answer to all my makefile blues.
2004-10-20 VI If you follow the instructions above for the free install, you end up with the resulting binary depending on msvcrt7.dll. That is a pain because most Windows only have the generic msvcrt.dll. Also note that the visual studio net sdk, (where the msvcrt.lib is) always ends up on the c:\program files irrespective of where you told it to install the .NET sdk. I instead got the DDK CD (Free, shipping is charged though) from http://www.microsoft.com/whdc/devtools/ddk/orderddkcd.mspx
. Then I linked against the msvcrt.lib under the lib/w2k/i386 directory. That gave me a tclsh without a dependency on msvcrt7.dllGWM This must be a new meaning to the word free that I am unaware of (or MS changed their prices) apparently it will cost $199 ($597 for three, so it isn't just shipping).If you use the path setups like above (which I did), then the makefile doesn't work because it expects MSVCDIR to be set. Just delete those lines in the makefile.vc in both tcl and tk.To build (assuming they are extracted to parallel dirs):
cd tcl8.4.7\win nmake nmakehlp.exe nmake -f makefile.vc INSTALLDIR=c:\tools\tcl\8.4.7 nmake -f makefile.vc INSTALLDIR=c:\tools\tcl\8.4.7 install cd ..\..\tk8.4.7\win nmake -f makefile.vc TCLDIR=..\..\tcl8.4.7 INSTALLDIR=c:\tools\tcl\8.4.7 nmake -f makefile.vc TCLDIR=..\..\tcl8.4.7 INSTALLDIR=c:\tools\tcl\8.4.7 installAnd the customary demo:
c:\tools\tcl\8.4.7\bin\wish84 c:\tools\tcl\8.4.7\lib\tk8.4\demos\widgetThe resulting binaries were run on win98 and the demo worked fine.
AR When compiling Tcl/Tk 8.4.19 on Windows XP with Visual Studio Express 2008, the resulting (installed) executable file does not launch (MSVC90.dll not found). This is because the manifest file must be incorporated. It can be done by inserting command:
mt.exe -manifest Release\tclsh84.exe.manifest -outputresource:Release\tclsh84t.exebefore doing the installation.
CLN I guess I'm really missing something 'cuz I installed the VC++ toolkit and the Platform SDK and I don't seem to have any file matching *MAKE.exe on my system. :-(PT In the installed Platform SDK look in: "C:\Program Files\Microsoft SDK\Bin\Win64" for NMAKE.exe. The Microsoft Driver Development Kit (DDK) also provides nmake, masm and some other handy bits.
See also How to create a minimal Visual C++ install
