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

[Gustaf Neumann]

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.
-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien