No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Re: Bug: configure step chooses wrong tclsh [REASONING]
From: Jim Lynch <jim_at_jam.sessionsnet.org>
Date: Sat, 10 Apr 2004 16:19:28 -0700
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
Date: Sat, 10 Apr 2004 16:19:28 -0700
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