| Areas | The project areas |
| Good if student knows | Desired knowledge |
| Priority | High |
| Difficulty | Medium-Hard |
| Benefits to the student | List benefits |
| Benefits to Tcl | List benefits |
| Mentor | Mo Dejong |
Mo Dejong One thing that really holds Tcl back as far as extensions go is the build process. It is simply too difficult to create Tcl C extensions because autoconf has a high learning curve, and it is very hard to have any confidence that any given set of build commands will actually work on other platforms. Python has a nice feature that lets an extension author build C code with the currently installed python. This should be a standard part of Tcl. All an extension author should need to provide is a list of the .h and .c files in the extension, then the build system should compile those files using the rules defined when Tcl itself was build on that platform. There is no viable solution to building Tcl and Tk without the autoconf tools due to the bootstrap issue, but there is no reason every extension author should have to create an autoconf based build and test on every platform. I would be interested in helping a student implement just such a project.
Some URLs here
stevel Are you aware of Critcl and how it can be used to build extensions? A simple example is on the fork page and many others are at Critcl examples. Sure, it isn't part of "the core" per se, but Critcl is a self-contained Starkit that doesn't require Tcl/Tk to be installed on the build system. It can even cross-compile, building Windows extensions on a *nix platform. Critcl can be used to build extensions in C, C++ and Fortran (see Critcl goes Fortran - useful when adding GUIs to legacy numerical programs).
hat0 I think the more important idea is that of a single "blessed" method of building extensions, whether it's critcl or a separate (not autoconf-based) process. A developer shouldn't have to download some extra stuff to build a simple extension. (Do you want to push for critcl's inclusion in the core distribution? if not, why not?)
Lars H: Note that there's a difference between building an extension and developing an extension. I believe building doesn't depend on autoconf being installed, since typically source distros typically come with pre-generated outputs (the configure and Makefile.in files) of autoconf, so "only" very standard Unix tools are needed. But if doing development (e.g. adding a source file) you need autoconf to regenerate those files.
Is Mo's point that the configure script shouldn't be needed either, on account of all the "intelligence" in that having been exercised already when Tcl/Tk itself was built, and that Tcl itself therefore should "know" how to perform builds for this platform and combination of configure flags? (A catch might be that it is not unusual to get a binary distribution of the core, but not of the extension in question.)
hat0 Yes, I believe that is his concern. I too was referring to developing extensions, not just compiling them.
SEH: So, what if Critcl had an option to configure itself by parsing the makefile generated by the configure script? Would that be an advance toward the stated goal?
hat0 Yes, but even better would be if the build mechanism could configure itself by reading out the settings stored in tcl::pkgconfig and guarantee the correct settings for the developer's system.
SEH: A while back I suggested a similar project involving SWIG. Critcl is more featureful, but SWIG has the advantage of being much more well-known and used. How about a project in which both SWIG and Critcl are enabled to compile stubs-enabled extensions based on tcl::pkgconfig settings?
... I've been made to understand that there's not enough information in tcl::pkgconfig to get the job done. So I guess the scope of the project expands to getting tcl::pkgconfig stocked up with enough information to make build configuration feasible?
CMcC - 2010-05-03 21:24:04
What critcl does: permits representation of C code in a Tcl wrapper, runs compilers over it and (optionally) generates a complete loadable package.
This is very useful if you want to generate loadable packages comprised of C code without dealing with the Tcl build system. Critcl is a build system, it doesn't even try to address how you might deliver those packages to a third party, it's not a distribution mechanism.
For Critcl to be a part in the delivery of source to end users, it would presuppose that those end users had access to a C compiler, linker, Tcl headers, etc etc. This isn't a safe bet, and begs the question of how they're to get and install a C compiler, linker, build system. That problem dwarfs the problem of delivering a binary extension.
I do not think that expecting a developer to download critcl is a big ask, although it could obviously be made even simpler by critcl's being packaged in tcllib or even the core.
In a way, the apparent misunderstanding of what critcl does is interesting, and investigating its cause might be productive. Critcl has several really excellent and revolutionary ideas:
3 and 4 above are somewhat antithetical - Critcl has two modes, essentially (cached compilation and auto-packaged compilation)
I do think that critcl would be better targeted at the auto-packaging use if it were presented as a simple script, and that this would make critcl itself an object of further development and refinement, and would attract people to further develop it, which I think would benefit everyone.
LV Providing an optional way to build very simple extensions seems like a useful provision. Of course, the caveats for the simple path will include things like "your platform has to include the following tools" - since if J Developer has decided to build an extension, and is using ActiveTcl or some other Batteries Included distribution as a base, they won't necessary have the same compiler, libraries, etc. as was used during the building of the binary distribution.
Another caveat would be that the extension use only those features used by Tcl and Tk. When the autoconf/etc. tools are being used as intended, they ensure that the build process verifies that all required library functions are present, specific utilities are present, etc.
arjen - 2010-05-04 02:55:02
The goals of my Fortran wrapper and Fortran-Tcl interface library (http://ftclsf.net ) are somewhat akin to Critcl: provide an easy way to deal with the interfacing. A difference is that I do not (really) support on-the-fly compilation. The focus is on packaging instead. (I avoid using autotools, as they have very bad support for Fortran and for most Fortran code I deal with, certainly in this context, it is simply overkill).
At the 9th European Tcl/Tk Users Meeting, Paul Obermeier suggested adding to SWIG the ability to generate TclOO classes from C++ class files.
arjen - 2010-10-22 10:02:25
I have had excellent experience with CMake (http://www.cmake.org ) as an alternative to autotools.