From owner-freebsd-current Sun Feb 27 15:40:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 6AE3937B6D1 for ; Sun, 27 Feb 2000 15:40:45 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id SAA91622; Sun, 27 Feb 2000 18:32:01 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Sun, 27 Feb 2000 18:31:51 -0500 (EST) From: Chuck Robey To: "Daniel O'Connor" Cc: Alex Zepeda , Will Andrews , Joel Ray Holveck , bwoods2@uswest.net, Maxim Sobolev , freebsd-current@FreeBSD.ORG Subject: Re: kdelibs port broken? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 28 Feb 2000, Daniel O'Connor wrote: > > On 27-Feb-00 Chuck Robey wrote: > > > This happens for tcl, gtk, qt.. There are quite a number. (at least 3! ;) > > Can I ask you, why could this not have been done through a system of > > symlinks and a little batch-file to switch them? > > How could you run multiple applications which use different versions of the > same library? A lot of them have support files which are loaded by the > library when ITs loaded by the app. You would end up with all sorts of nasty > race conditions when people run multiple apps etc.. The config files that I would be controlling aren't used during program runtime, only during build. The stuff would link just as it is now, but you'd use a short "versioning" script to set up the config file symlinks, so that if you wanted to build a app that wasn't a FreeBSD port, it would find it's correct config file, right where it expects to find it. Some stuff, like tclsh, could have a default link, say from tclsh to tclsh8.2, or allow a user to set that. That could be a local option, but it's icing on the cake as far as I'm concerned. The only real thing I would be after is the ability to stick the config file locations in the places that the original developers (and the configuration scripts they build with) expect them to be. Anything done as far as executeable names, I don't really care too much about. ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@picnic.mat.net | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message