No registered users in community xowiki
in last 10 minutes
in last 10 minutes
[Xotcl] Re: Status of the bugs I reported/could people resend their replies to those bugs
From: Jim Lynch <jim_at_jam.sessionsnet.org>
Date: Tue, 6 Apr 2004 07:06:16 -0700
Hi Gustaf...
On Mon, 5 Apr 2004 20:51:09 +0200
"Gustaf Neumann" <neumann_at_wu-wien.ac.at> wrote:
> On Friday 02 April 2004 05:37, Jim Lynch wrote:
> > Hi,
>
> Hi Jim,
> sorry for the delayed answer, i was last week on vacation.
>
> > Last month I reported three bugs in the configure step of the xotcl
>
> you mean last week? well, last week is also last month, just to remove
> disambiguity, i have received no earlier mails from you.
>
> > build process. While I was reporting those bugs and for a few days
> > after, I was working on my mail, and so turned off the list's replying
> > to me at first.
> >
> > Is there a different way to report bugs? Could someone tell me the
> > status of these bugs? Would anyone like copies of the bug reports
> > sent to them?
>
> as uwe pointed out, we have since last week serious hardware
> problems on our webserver.
>
> i have received four mails from concerning a) the aolserver, and b)
> tclsh without path.
>
> concerning (a) you are right, determining to build with AOLserver
> from the `pwd` is not pretty, also the hardwired path to the
> AOLserver include directory. i have changed that
> right now. note, that making an aolserver module is only an issue
> for AOLserver 3.*, the AOLserver 4* series does not require this
> at all. Therefore, i have named the configure switch
> --with-aolserver3=AOL_INCLUDE_DIR
> where you have to specify the include directory.
Suggestion, howbout the prefix dir instead? That way, any time you add
dependendency on another kind of thing, you already planned for the
stem dir. Besides, if this switch is to represent the include dir, it
is misnamed, and should be named something like --with-aolserver-inc=.
So if you said to aolserver, "./configure --prefix=/x/y ...", then you'd
say to xotcl, "./configure --with-aolserver3=/x/y ..."
> Concerning the second problem, you wrote:
> >When configuring xotcl to build with a tcl which is not the system tcl,
> >the configure step assumes the tclsh in the $PATH, which is a wrong
> >assumption.
> >
> >The right assumption would be to choose the tclsh located in the tclConfig.sh.
> >
> >Doing this would ensure the builder will get the tclsh which is in the
> >installation of tcl he/she specified.
>
> well, can you be more specific, where this happens?
> XOTcl uses in configure.in SC_PROC_TCLSH
> and uses in all the Makefiles $TCLSH_PROG as far i can see.
> What version of xotcl are you working with?
I'm using xotcl-1.2.0; my situation is I'm building using a tcl
I built specifically for an aolserver4. It's not the system tcl
and its bin dir is not in my path.
As far as I've been able to determine, the tclsh which is called
has to be able to find the libxotcl thing. Apparantly, not every
tclsh I have is able to do that, so I looked closely at the
SC_PROG_TCLSH macro (having traced the problem down to that macro)
and noticed that it doesn't try to use the tclsh specified in the
supplied tclConfig.sh, which as far as I know is the only correct
choice (should use the tclsh linked to the same libs that were
used in the build process of xotcl, and that can find the modules).
The fix for this is easy, and a patch has already been sent to the list.
> -gustaf
-Jim
Date: Tue, 6 Apr 2004 07:06:16 -0700
Hi Gustaf...
On Mon, 5 Apr 2004 20:51:09 +0200
"Gustaf Neumann" <neumann_at_wu-wien.ac.at> wrote:
> On Friday 02 April 2004 05:37, Jim Lynch wrote:
> > Hi,
>
> Hi Jim,
> sorry for the delayed answer, i was last week on vacation.
>
> > Last month I reported three bugs in the configure step of the xotcl
>
> you mean last week? well, last week is also last month, just to remove
> disambiguity, i have received no earlier mails from you.
>
> > build process. While I was reporting those bugs and for a few days
> > after, I was working on my mail, and so turned off the list's replying
> > to me at first.
> >
> > Is there a different way to report bugs? Could someone tell me the
> > status of these bugs? Would anyone like copies of the bug reports
> > sent to them?
>
> as uwe pointed out, we have since last week serious hardware
> problems on our webserver.
>
> i have received four mails from concerning a) the aolserver, and b)
> tclsh without path.
>
> concerning (a) you are right, determining to build with AOLserver
> from the `pwd` is not pretty, also the hardwired path to the
> AOLserver include directory. i have changed that
> right now. note, that making an aolserver module is only an issue
> for AOLserver 3.*, the AOLserver 4* series does not require this
> at all. Therefore, i have named the configure switch
> --with-aolserver3=AOL_INCLUDE_DIR
> where you have to specify the include directory.
Suggestion, howbout the prefix dir instead? That way, any time you add
dependendency on another kind of thing, you already planned for the
stem dir. Besides, if this switch is to represent the include dir, it
is misnamed, and should be named something like --with-aolserver-inc=.
So if you said to aolserver, "./configure --prefix=/x/y ...", then you'd
say to xotcl, "./configure --with-aolserver3=/x/y ..."
> Concerning the second problem, you wrote:
> >When configuring xotcl to build with a tcl which is not the system tcl,
> >the configure step assumes the tclsh in the $PATH, which is a wrong
> >assumption.
> >
> >The right assumption would be to choose the tclsh located in the tclConfig.sh.
> >
> >Doing this would ensure the builder will get the tclsh which is in the
> >installation of tcl he/she specified.
>
> well, can you be more specific, where this happens?
> XOTcl uses in configure.in SC_PROC_TCLSH
> and uses in all the Makefiles $TCLSH_PROG as far i can see.
> What version of xotcl are you working with?
I'm using xotcl-1.2.0; my situation is I'm building using a tcl
I built specifically for an aolserver4. It's not the system tcl
and its bin dir is not in my path.
As far as I've been able to determine, the tclsh which is called
has to be able to find the libxotcl thing. Apparantly, not every
tclsh I have is able to do that, so I looked closely at the
SC_PROG_TCLSH macro (having traced the problem down to that macro)
and noticed that it doesn't try to use the tclsh specified in the
supplied tclConfig.sh, which as far as I know is the only correct
choice (should use the tclsh linked to the same libs that were
used in the build process of xotcl, and that can find the modules).
The fix for this is easy, and a patch has already been sent to the list.
> -gustaf
-Jim
-- Jam sessions community web site: http://jam.sessionsnet.org