Re: can't run xconq due to BWidget

[Hans Ronne <hronne at pp dot sbbs dot se>]

>  | I suspect the correct answer is something along the lines of:
>  |
>  |   lappend auto_path [env get XCONQLIB]/../tcltk/BWidget
>
>+ lappend auto_path [file join $env(XCONQLIB) ../tcltk/BWidget]
>- lappend auto_path tcltk/BWidget
>it seems to work.

Yes. But not for MacOS and Windows. So we really need a special case for Unix:

if { "$tcl_platform(platform)" == "unix" } {
	lappend auto_path [file join $env(XCONQLIB) ../tcltk/BWidget]
} else {
	lappend auto_path tcltk/BWidget
}

BTW, I didn't notice this bug because I always run the Unix app from the
top directory:

cd xconq
x11/xconq

Which brings us to the root of the problem. For historical reasons, the
Unix apps build in the x11 directory. This does not make sense at all for
the tcltk app, which should live in the tcltk subdirectory if not in the
top directory. Having the binaries in different locations for different
platforms also makes the library search paths extremely complicated. In
fact, I think there are still some unusual cases (apart from the current
bug) where they will fail.

I therefore think a better long-term solution would be to build all
binaries (xtconq, xconq, sdlconq, cconq, skelconq, MacTCL, MacPPC, MacSDL,
WinTCL, WinSDL etc.) in one place (the xconq top directory). This would
life easier for the coders, probably also for the users. Comments?

Hans

Hans Ronne

hronne@pp.sbbs.se