Critcl Discussion

AK Ideas

• Replace the current blind usage of gcc with calls into a tcl based build system to make this code platform independent.
• Make code in tcllib conditional on the availability of such a build system. I.e. Pure Tcl if there is no build system, and compiled code else.
• With an omni-present build system we can do away with the restriction of not using C code / extensions in Tcllib. -- Later -- But the build system is not omnipresent, unfortunately. So scratch this idea.
• deployment of C extensions in wrapped application becomes easy. Code is deployed in source and compiled and cached on site. But relies on presence of a compiler on the site. -- Later -- Which makes this a not so good idea after all.
• Alternative is to compile before deployment and use the existing methods to load the code dynamically.
• The ideas above require that Build system and Critcl are distributed along with the core itself, like http, dde, and reg.

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.

DGP

(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

AK Clarifications.

• What Donal says is essentially correct and I have now added clarification to the items which were not so good ideas after all.
• I am not sure how this thought came to be, but I did not advocate to use Critcl to create a build system. What I did thought about was to take whatever build system will come out of TIP 34 and 59 and sucessors and let Critcl use that instead of hardcoding the usage of gcc into it.

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 [L1 ]) 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