Tk Library Source Code

Installing tcllib from CVS head with a prefix:

  ./configure --prefix=/home/me/local/tclllib-HEAD
  make install

  $ ~/local/tcllib-HEAD/bin/dtplite


If no other tcllib is installed then dtplite errors out -- it can't find a tcllib (this is the case e.g. on sourceforge)

If there's a tcllib installed on the system then dtplite prefers that, making testing of new version tricky.


Can the utility commands that ship with tcllib always link against the version of tcllib they ship with?

Logged In: YES 
user_id=75003
Originator: NO

Oops on the typo, apologies.

Regarding bindir/libdir/prefix ... That is the part I had not yet looked into. Given your explanations it is now clear that I have to put a placeholder into the code of dtplite, and modify tcllib's installer to replace them with the correct path during installation ...

That is a pain, because for ActiveTcl (*) I will have to replace the placeholder with a placeholder, or not at all, so that the distribution's installer can do the final replacement :(

(*) Any other batteries included distribution will have the same problem.

It is not clear why the linsert works but not the lappend. Package management reads all pkgIndex.tcl files in all paths, and later simply asks for a package satisfying the requested version. Only for packages with multiple implementations but the same version should order become important :(

Note that 'tcllib 1.9' is not relevant information. The version of the 'doctools' package counts. Which is 1.3 in tcllib 1.10, and was 1.2.1 in tcllib 1.9. dtplite simply asks for doctools, no version, so should get the highest. If that is not the case something else is wrong. Or the tcllib 1.9 you have is from a CVS head and already at v1.3.

Logged In: YES 
user_id=87254
Originator: YES


Small typo. lappend auto_path is missing in the second arm:

    if {[file exists [file join $topdir modules]]} {
        lappend auto_path [file join $topdir modules]
    } elseif {[file exists [file join $topdir lib]]} {
        [file join $topdir lib]
    }


Anyway, the above prefers the older version of tcllib (1.9 on my machine, distro installed) unless I do this:

    if {[file exists [file join $topdir modules]]} {
        set auto_path [linsert $auto_path 0 [file join $topdir modules]]
    } elseif {[file exists [file join $topdir lib]]} {
        set auto_path [linsert $auto_path 0 [file join $topdir lib]]
    }

With the above change, dtplite finds and uses the correct version of tcllib when
installed with --prefix. Without the change, it uses a mish-mash of old and new tcllibs.

However...

I'm not sure this is the right fix in the general case. It's not really a question
of --prefix but --libdir, as that is what is used in the Makefile to install:


    pkglibdir = $(libdir)/@PACKAGE@@VERSION@
    ...
    install-libraries:
        $(TCLSH_PROG) `$(CYGPATH) $(srcdir)/installer.tcl` \
        -pkg-path   $(DESTDIR)$(pkglibdir) ...


There is not necessarily a direct relationship between libdir and bindir, as both can be set independently on the configure command line. And that means you can't find your way to libdir by starting with [info script].

For example, I already have tcllib-1.9 installed in /usr/share/tcl8.4 (standard fedora 7 rpm), with dtplite in /usr/bin, and to make sure the above fix works without passing a weird --prefix I wanted to install to /usr/share/tcl8.4, which is in my Tcl's library path.

The directories tcllib1.10 and tcllib1.9 do not clash, but the dtplite script would overwrite the existing one in /usr/bin. So I used:

  ./configure --bindir=/home/sd/tmp/bin --libdir=/usr/share/tcl8.4

which doesn't work. dtplite picks up tcllib-1.9.



So the above fix works for a standard install where tcllib lives somewhere on the Tcl package path. And it works if you install somewhere non-standard by using --prefix at configure time. But it doesn't work if you install somewhere non-standard by using --libdir and/or --bindir/--exec-prefix.

I think the usual way people handle relocatable autoconf packages is by embedding the paths in the scripts/binaries and/or using -rpath. Not sure if you want to handle that here.

Logged In: YES 
user_id=75003
Originator: NO

I have now attached a small tcl script, "dtplite.autopath.tcl", which may fix the problem. Its contents have to be inserted after the 'exec tclsh' at the top of dtplite. The code basically computes the location of dtplite itself, then looks into the filesystem for the two places where tcllib modules can be and adds the one it found to the package management.

It should not only be tested that this fixes the problem, but also that it doesn't break the regular setup, i.e. when installed without a --prefix.

File Added - 247453: dtplite.autopath.tcl

Logged In: YES 
user_id=75003
Originator: NO

File Added: dtplite.autopath.tcl

Logged In: YES 
user_id=75003
Originator: NO

Hm. dtplite simply does 'package require doctools' and then assumes that the package management of the Tcl core will be set up to find it. When you installed tcllib into the local directory, was the tclsh you used correctly set up to find packages in that directory ?

Note, if I add code like 'lappend auto_path ...' to extend the package search from within dtplite, then testing an uninstalled dtplite will be come difficult too ...

I will have to look where tcllib and dtplite go, i.e. both prefix ? Is exec-prefix involved. If things are simple enough I should be able to write code which properly extends package search for all cases ...