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 that >> links 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 not look in the depot. Passing the -L -I PKG_CONFIG_PATH etc flags to link to the stuff in the depot 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. Peter -- Peter O'Gorman http://pogma.com _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
