The following patch should solve the problem.
One way of applying it:
- save it to a file, say "xotch-1.2.0/choose-right-tclsh.diff" - cd xotcl-1.2.0 - cat choose-right-tclsh.diff | patch -p1
Once you have done this, you must run autoconf to regenerate the script "configure". Following this, the configure script will always choose the tclsh specified by the supplied tclConfig.sh.
---- cut here ---- diff -Naur xotcl-1.2.0-orig/unix/configure.in xotcl-1.2.0/unix/configure.in --- xotcl-1.2.0/unix/configure.in 2004-01-28 00:20:39.000000000 -0800 +++ xotcl-1.2.0-work/unix/configure.in 2004-04-05 06:49:39.000000000 -0700 @@ -471,7 +471,26 @@ # versions have bugs in the pkg_mkIndex routine. #--------------------------------------------------------------------
-SC_PROG_TCLSH +#-------------------------------------------------------------------- +# tclsh should be at $TCL_PREFIX/bin/tclsh$TCL_VERSION after +# loading tclConfig.sh, so: test for this file; do equiv of +# SC_PROG_TCLSH if found, otherwise complain about error. +# Require (instead) that we use the tclsh -specified- by +# tclConfig.sh since others won't be able to do things like +# find the right module/lib files, etc. +# -Jim Lynch +#-------------------------------------------------------------------- + + +if test -x "$TCL_PREFIX/bin/tclsh$TCL_VERSION" +then + TCLSH_PROG="$TCL_PREFIX/bin/tclsh$TCL_VERSION" + AC_MSG_CHECKING([for tclsh]) + AC_MSG_RESULT(found at $TCLSH_PROG) + AC_SUBST(TCLSH_PROG) +else + AC_MSG_ERROR(the appropriate tclsh was not found) +fi
# # XOTcl specific configs ---- cut here ----
-Jim
-- Jam sessions community web site: http://jam.sessionsnet.org
Hi,
I've been talking to people on the irc channel, Jeff Hobbs among them, about the tclsh issue. Jeff's contention, as far as I understand it, is that if tclsh is not used to actually load the extension it's building, any tclsh will do, and that the TEA_PROG_TCLSH macro uses a more correct ordering to find tclsh: so long as the supplied tclConfig.sh refers to its tclsh, that tclsh ought to be found first.
Among other things, I'm now trying to determine whether the build process of xotcl actually needs that specific tclsh or not; right now my guess is that it does.
-Jim
-- Jam sessions community web site: http://jam.sessionsnet.org
On Friday 09 April 2004 16:04, Jim Lynch wrote:
Hi,
I've been talking to people on the irc channel, Jeff Hobbs among them, about the tclsh issue. Jeff's contention, as far as I understand it, is that if tclsh is not used to actually load the extension it's building, any tclsh will do, and that the TEA_PROG_TCLSH macro uses a more correct ordering to find tclsh: so long as the supplied tclConfig.sh refers to its tclsh, that tclsh ought to be found first.
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
By googling around, i found http://cvs.sourceforge.net/viewcvs.py/tcl/sampleextension/configure.in?rev=1... 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
- 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.
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?
-gustaf neumann
Among other things, I'm now trying to determine whether the build process of xotcl actually needs that specific tclsh or not; right now my guess is that it does.
-Jim
-- Jam sessions community web site: http://jam.sessionsnet.org _______________________________________________ Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
Gustaf Neumann wrote:
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
By googling around, i found http://cvs.sourceforge.net/viewcvs.py/tcl/sampleextension/configure.in?rev=1... 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
Actually the sampleextension-0.2 is years old, and I should remove the entire www.tcl.tk/doc/tea/ area, since I haven't had time to correct the old docs. Most major extension all use TEA2 now (some use TEA3 in fact, which is relatively recent). SC_PROG_TCLSH is NOT the way to go. Note that the core does not use TEA (Tcl Extension Architecture) because it is not an extension.
On Saturday 10 April 2004 22:54, Jeff Hobbs wrote:
Actually the sampleextension-0.2 is years old, and I should remove the entire www.tcl.tk/doc/tea/ area, since I haven't had time to correct the old docs. Most major extension all use TEA2 now (some use TEA3 in fact, which is relatively recent). SC_PROG_TCLSH is NOT the way to go. Note that the core does not use TEA (Tcl Extension Architecture) because it is not an extension.
ok.
i looked into http://sourceforge.net/projects/incrtcl, which contains itcl3.2.1, which uses still the SC_* macros (i got there by clicking on project "incrtcl" on http://www.tcl.tk/software/tcltk/netcvs.html).
i have checked out the version from there, it uses TEA_* macros. jeff, is this TEA2 or TEA3? i got as well tcl.m4 from cvs tcl/tclconfig, which appears to be more recent. in both files, i find not hint whether this is based on TEA2 or TEA3.
Where is TEA3 documented? Is there a better documentation than the comments of the macros?
-gustaf neumann
i looked into http://sourceforge.net/projects/incrtcl, which contains itcl3.2.1, which uses still the SC_* macros (i got there by clicking on project "incrtcl" on http://www.tcl.tk/software/tcltk/netcvs.html).
i have checked out the version from there, it uses TEA_* macros. jeff, is this TEA2 or TEA3? i got as well tcl.m4 from cvs tcl/tclconfig, which appears to be more recent. in both files, i find not hint whether this is based on TEA2 or TEA3.
itcl 3.2 used TEA1 (which was SC_* macros). The itcl in CVS uses TEA2 (which is TEA_* macros, but unversioned). You should see that the tcl/tclconfig (and related tcl/sampleextension) is TEA3 - it includes a specific TEA_INIT([<VERSION>]) in it (to alleviate more version confusion in the future).
Where is TEA3 documented? Is there a better documentation than the comments of the macros?
It's all the comments in the sample extension and in the macros at this point unfortunately. If you've used TEA before, then it should be easy to move over. One of these years I'll get some time to document this better, but that's not going to happen soon. :/
Jeff
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
On Sunday 11 April 2004 01:19, Jim Lynch wrote:
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?
there are many tcl.m4; the one used in xotcl is from an itcl verison.
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.
i did not argue that SC_PROG_TCLSH finds the right tclsh. the right approach is not to modify SC_PROG_TCLSH in a way such it works more correcty in situation like yours (this might break other cases, where people depend on the behavior of SC_PROC_TCLSH), but to move to the new TEA macros, that i finally found.
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 :)
well, you do not have a simple setup, now i can understand your situation more clearly. it is a tricky setup where using the wrong file-set can lead to problems not easy to figure out.
however, we will get this working.
i have just now converted the xotcl build stuff to TEA3 (at least, i believe that this is now TEA3). The good news is that the configure/make stuff became less code. I am certainly not through, but at least make make test make install-aol seems to work. I have still to work through the various configure options, the subdirectories have to be adjusted as well.
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?
i have the constant hope that the configure/build somehow settles and will become stable. furtunately, TEA3 looks nicer then what we had before, configure.in and Makefile.in for xotcl is about 20% shorter (maybe more can be removed). If we can find a maintainer for this stuff, we would certainly be happy.
-gustaf PS: if you are interested on getting the TEA3 stuff just now, and/or you are willing to help, please drop me a line.
-
Gustaf Neumann -
Jeff Hobbs -
Jim Lynch