On Apr 1, 2008, at 1:27 AM, Florian Ebeling wrote:
Maybe I'm too ignorant, but isn't also the fact that dependencies are version-agnostic one major cause of build fails and probably a cost-effective gain to change?
Not ignorant at all, yes, this is a well-known shortcoming of dependencies. No way to specify minimum version, maximum version, range of versions, and so on. Package systems like RPM do, but lacking this in the base system means MacPorts can't make more intelligent dependency decisions and it can't pass those on to the packaging system, which will need to make the same decision if the user uses packages to install instead. I think "new dependency engine" has even been on the task list for for several years now.
I'm rather new to macports, but I was delighted to find that it can keep multiple versions installed, with only a single one active (usually) -- only to learn later then that it is otherwise not using this feature, really.
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.
To be fair, and make no mistake, it's actually pretty hard to get this right. Smashing everything together in a common $prefix and assuming that all your deps are part of $prefix at any given time is a hugely simplifying assumption, too. For most ports, a simple -I${prefix}/ include and -L${prefix}/lib is all the stands between their vanilla state and working properly with MacPorts. In a true multiple-version world, each and every dependency potentially adds to the search paths.
- Jordan _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
