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: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 11 Apr 2004 05:09:57 +0200
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.
Date: Sun, 11 Apr 2004 05:09:57 +0200
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