I don't follow most of the AK ideas above. My impression was that the reason for the "no compiled code" rule in tcllib was because we did not want to require a compiler on the user's machine in order for the user to use all of tcllib. There's nothing here that provides a compiler, so I don't see how the nifty features provided by Critcl change anything about whether or not to include C-coded packages in tcllib.
(Please read the above as "AK's ideas", not mine)
I am not sure that extending Critcl to create a build system of some sort would be my first goal. The model I have is a group of developers, all fed up with build issues (and with a standard C compiler within reach at all times), and the rest of the world (trying to never have to find out what a "compiler" is, let alone allow one on their machine). In this context, Critcl is way cool for developers IMO, yet useless for the majority of people on this planet.
For deployment, I always use Tclkit. Once Critcl gains the capability to build all C packages into either a shared or a static lib, it will be helpful for any developer with the same type of machine as their clients to press a button, wrap all C code up, package the app into some standalone system (not necessarily Tclkit of course), and never look back.
From where I stand, the best delivery mode to developers is source code (unless it's so standard that a binary is more convenient and is supplied by a trusted source), while the best deployment mechanism to reach everyone else is always: portable scripts + binaries, usually wrapped up in some way.
Does Critcl need a build system? I'm not convinced... - JCW
PT 2003-May-02: For an example of optionally extending tcllib using critcl have a look at the md4 module and the DEVELOPMENT branch of the base64 module (specifically the uuencode and yencode packages). These files include C code to be built with critcl. If tcllib is being packages as a starkit or starpack then using critcl to build the base64c, md4c and md5c packages will enable compiled code for the supported platform. Critcl packages are already installed into a platform dependent subdirectory so for supported packages we get normal tcllib functionality with compiled speed, while for other platforms we still have the pure tcl versions. Personally I think this is the best of all worlds.
CMcC: I'm a big fan of SWIG, but it's so much easier to deliver extensions (at least small ones) with Critcl because you can put the whole extension into only one source object, where SWIG source distribution requires at least an interface description, a Makefile (to be useful) and (usually) a .tcl to wrap and sugar it up. You can generate the .so file into ., and package it up as a .tar.gz having run it once. Very convenient.
I don't understand why setting the outdir to local stops automatic recompilation. There doesn't seem to be any really good reason for that, and it gave me a few unexpected results.
I don't see the problem with expecting the user to install Ming under Windows - it's free after all.
Compilation errors could perhaps be thrown, so you don't have to root around in ~/.critcl to find out what happened, and the special case of a lack of C compiler could be handled by a URL for downloading a free C compiler under Windows. I'm presuming most people have gcc under Unix.
Finally, since tclkit can handle .so and .dll loading, and Critcl can produce them on the developer's machine, and since Critcl gives you the significant win of being able to package a whole small extension into a single .tcl, I think it's a win for both binary and source distributions.
Thanks for the comments, Colin. The critcl mechanism is still in flux, the most recent work has been to create a self-contained package. It does catch and present errors somewhat better. The "outdir" mechanism is tricky (several features still are quite experimental), but with the packaged version of critcl (by Steve Landers, see [1 ]) it is no longer needed. See the Critcl page, which has just been updated with more info and examples.
Your comments in the last paragraph are exactly why I think the use of "outdir" is already becoming less important. What I tend to do is develop inline, and simply never bother about how binaries are dealt with, and then when it's ready for deployment, I run "critcl -pkg myscript.tcl" to create shared libs. -jcw