On Apr 2, 2008, at 3:44 PM, Peter O'Gorman wrote:
Eric Hall wrote:On Tue, Apr 01, 2008 at 02:02:57AM -0700, Jordan K. Hubbard wrote:On Apr 1, 2008, at 1:27 AM, Florian Ebeling wrote:This is sadly somewhat controversial. I think dependencies should definitely be directed at the depot location, e.g. something thatlinks with, say, jpeg version 6.2, shouldn't link to /usr/lib/ libjpeg.62.dylib but rather /opt/local/var/macports/software/jpeg/6b_2/opt/ local/lib/libjpeg.62.dylib, and so on and so forth for any absolute- path dependencies. Then whether something is "active" or not has nothing to do with whether it can be depended on. Every time the subject comes up, however, various people rapidly get the creeping crawlies and we lose the courage to actually attempt this.I've always thought this was an excellent idea, it neatly solves conflicting version problems (libnet for example) and allows a new version of $THIS_DEPENDENCY to be installed without breaking$OTHER_SOFTWARE that's linked against $OLDER_VERSION_OF_THIS_DEPENDENCY,and/or resulting in the massive rebuild fsck to bring everything back to happyness when a dependency is upgraded.It does not solve all that much, as all the embedded paths are still /opt/local, the install_name of the libs is still /opt/local,applications will still look for resources in /opt/local, they will notlook in the depot.Passing the -L -I PKG_CONFIG_PATH etc flags to link to the stuff in thedepot will have absolutely no effect on the resulting binary, making such a change, imo, pointless, older versions of things will still be broken when you update some dependency.
I also worry about cases like when A links against B and C. B was linked against D.version1 while C was linked against D.version2. Thus when A loads, it pulls in two (?) potentially incompatible versions of D?
James
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
