On Sat, 10 Apr 2004 21:01:53 +0200 "Gustaf Neumann" neumann@wu-wien.ac.at wrote:
I was not on the chat, but:
- Jeffs suggestion was to use the TEA_* macros instead of the stuff we use currently. I was not aware of these new TEA macros. the sample extension (sampleextension-0.2) in http://www.tcl.tk/doc/tea/ contains only SC_* macros, and no TEA_ at all. the same is with tcl8.4.6 find tcl8.4.6 -type f | xargs fgrep TEA_ On the other hadm it still uses SC_PROG_TCLSH, determined by find tcl8.4.6 -type f | xargs fgrep PROG_TCLSH
OK; right. Those macros are in tcl.m4, which xotcl also has a copy of. Are they actually copies of each other? Which one is actually used by autoconf, and under what circumstances?
By googling around, i found http://cvs.sourceforge.net/viewcvs.py/tcl/sampleextension/configure.in?rev=1.37 which is quite different from the macros. so... i come to think that SC_PROG_TCLSH is currently the way to go, but TEA2 will at some time do everything better with new TEA_* macros
But the order of checking is wrong... if you -happen- to have the right tclsh in your path before any other, that's when it will find the tclsh that was built with the right stuff.
- It is not arbitray, which PROG_TCLSH is used for xotcl: Since xotcl depends on some tclInt.h structures, which change from time to time, it is highly recommend to use a tclsh, which was compiled with the same tclInt.h as the xotcl extension (except you use the xotlc shells, which is deprecated). Mixing shells is as well a problem if you use theads e.g. for xotcl.
OK, given that, is not the best tclsh the one specified in the tclConfig.sh file? The SC_PROG_TCLSH does not look for that one first. Further, if any macro finds a different tclsh, you're saying here that it shouldn't be used, for at least all the reasons you just gave.
So, I contend it shouldn't use a macro with any search path which would bottom out to any ol' tclsh that might be found in the $PATH; if it doesn't find a tclsh specified in tclConfig.sh, that should be an error which can and should be caught right there.
on my fedora system i have tcl and xotcl in the same directory, configure finds the source version and places e.g. TCLSH_PROG = /home/neumann/tcl8.4.6/unix/tclsh to the Makefile. is this on your system different?
I can't count the number of different situations I have :) I also can't count the situations I'm going to have in the future :) But if the configure/build process is to be stablized, it should work with all of them. I think this is a good possibility, assuming after the initial work is done, that it's maintained.
But I can tell you about three of them that I know I do have:
o There is a system-wide tcl which was installed as a debian package; I don't use that myself. I like building, then I control what version I use. The tclsh for this tcl is in my $PATH, and therefore will be found by SC_PROG_TCLSH.
o There is a tcl-8.4.5 I built for use in a test jig. This is where I'm currently trying to find the build/configure problems in xotcl. Happens that the string "aolserver" is in the directory path to both the tcl source and its install prefix, so a previous but fixed problem would have assumed this tcl was for aolserver3.x and therefore compiled in support for it. Also happens that there is an aolserver4 nearby. This tcl was built for use with that aolserver4. This aolserver4 is loosely considered part of the test jig, but so is a nearby perl interpreter. The tclsh for this tcl is -not- in my $PATH, so is unlikely to be found first by SC_PROG_TCLSH even though most builds of xotcl I'm doing now use its tclConfig.sh.
o Finally, there is a tcl-8.4.5 built for a different aolserver4 located in a completely separate dir, /usr/local/aolserver. The username that can write to this dir is nsadmin; the tclsh in this tcl might be in nsadmin's $PATH; I don't remember for sure. This aolserver and tcl are used to support a few test instances of openacs, which I hope to try with xotcl, and to allow other openacs users to also do. Some openacs users and core developers have expressed great interest; it is for this reason I even start with xotcl at all. I am dumb as a stump with xotcl, I just know some things about building it :)
In summary here, I want to have xotcl be able to build in all three of these situations and many more. Early on, I had mentioned that I was unaware if my "help" in this area (make the configure/build work and be stable) is actually welcome, and I repose that question here and now, adding this: Once the build and configure processes are stable, will they be kept maintained that way?
-gustaf neumann
-Jim
-- Jam sessions community web site: http://jam.sessionsnet.org