Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Jan 1997 20:41:49 -0500 (EST)
From:      Chuck Robey <chuckr@glue.umd.edu>
To:        ports@freebsd.org
Cc:        committers@freebsd.org, ports-jp@jp.freebsd.org
Subject:   Re: multiple versions of tcl/tk
Message-ID:  <Pine.OSF.3.95.970118203515.27246C-100000@professor.eng.umd.edu>
In-Reply-To: <199701190124.RAA19157@baloon.mimi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 18 Jan 1997, Satoshi Asami wrote:

> I'm back.  It was quite cold up there in Tahoe.
> 
> Anyway, I ran into Dr. Ousterhout in the retreat, so asked him about
> the multiple versions problem.  He suggested we put the shared files
> (tk.h and tkConfig.sh) in subdirectories so that ports that require a
> specific version (for example, 4.1) can either:
> 
> (1) use the -I flag to gcc to specify the subdirectory (i.e.,
>     -I${PREFIX}/include/tk4.1), or
> 
> (2) edit the source and change the #include statements (i.e., <tk.h>
>     -> <tk4.1/generic/tk.h>)
> 
> I suggested that we also make a symlink from tk.h and tkConfig.h to
> the "default" version of the system, which he agreed is a good idea.
> 
> So, I will be committing changes to the tk41 port soon.  I will just
> rename /usr/local/include/tk to tk4.1 and install tk.h in there and
> change the direction of the symlink (right now it's tk/generic/tk.h ->
> ../../tk.h).  I'll also fix the ports that require the internal
> headers (camltk41, tix, expect, any others?).
> 
> This means I can now allow other versions of tcl/tk (7.3, 7.4, 7.6,
> 8.0 for tcl and 3.6, 4.0, 4.2 and 8.0 for tk) to be active in the tree
> iff someone makes the necessary changes to have them conform to the
> above standard (obviously Japanese versions will be taking the same
> path also).  Please contact me you are interested in doing the work.

This is a problem, Satoshi.  The file involved is tkConfig.sh.  It's the
one that all the other ports query for all their information, before
they're installed (during their build).  It's really the key one, since
all the other hiding has to be announced inside that file.

Ports look for it now in /usr/local/lib or /usr/local/include.  If you
want to do what you're talking about above, I would guess that the right
thing to do *might be* to hide multiple copies of the tkConfig.sh file
(for whatever version is involved) inside your version-specific hierarchy,
and take the hit on extra work configuring new tcl/tk applications.  This
means breaking all the automatic configurations for stuff that people put
in their machines *other than* stuff coming from our ports method.

Is this what you want to do?

> 
> Satoshi
> 

----------------------------+-----------------------------------------------
Chuck Robey                 | Interests include any kind of voice or data 
chuckr@eng.umd.edu          | communications topic, C programming, and Unix.
9120 Edmonston Ct #302      |
Greenbelt, MD 20770         | I run Journey2 and picnic, both FreeBSD
(301) 220-2114              | version 3.0 current -- and great FUN!
----------------------------+-----------------------------------------------




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.3.95.970118203515.27246C-100000>