[Xotcl] Re: Bug: configure step chooses wrong tclsh [REASONING]

[Jim Lynch]

On Sat, 10 Apr 2004 21:01:53 +0200
"Gustaf Neumann" <neumann at 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