From owner-freebsd-ports  Fri Sep 29 02:06:20 1995
Return-Path: owner-ports
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id CAA05960
          for ports-outgoing; Fri, 29 Sep 1995 02:06:20 -0700
Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA05944
          for <ports@freebsd.org>; Fri, 29 Sep 1995 02:06:05 -0700
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id CAA00926; Fri, 29 Sep 1995 02:05:17 -0700
Date: Fri, 29 Sep 1995 02:05:17 -0700
Message-Id: <199509290905.CAA00926@silvia.HIP.Berkeley.EDU>
To: ports@freebsd.org
Subject: tcl-7.4 / tk-4.0
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: owner-ports@freebsd.org
Precedence: bulk

What should we do with these little beasts?  I first let them generate
shared libtcl.so.7.4 and libtk.so.4.0, and then I found out that old
tcl/tk programs don't compile anymore (because ld will pick up the
newer versions automatically).  So I renamed them to libtcl74.so.1.0
and libtk40.so.1.0, and added "74" and "40" to the -l lines of the new
ports...then it was pointed out to me that since the new ports
overwrite tcl.h and tk.h, we can't compile the old stuff unless we
revert the headers back.  Ack.

We can change the headers to tcl74.h and tk40.h and go playing the
same trick, but I don't think that's the right solution.  For one
thing, it's ugly.  Another is that new ports will come out for tcl-7.4 
and tk-4.0, and we don't want to keep fixing them forever, as they
would all like to include tk.h and link against -ltk.  This has to
stop sometime.

Note that with the libtcl.so.7.4 and libtk.so.4.0 scheme, old programs 
will still run, it's just that you can't compile them anymore with the 
newer versions sitting around.

One "solution" is to admit that this is not going to work and put a
big banner in red, green and purple that funny things will happen if
you try to compile the old ports with the new stuff instaled.  I don't
think many people keep going back and forth compiling stuff, for
package building, I can live with a few top-down "make" runs with DUDS
and stuff.

Any ideas?

Satoshi