On 4/14/2010 6:58 AM, Trent Nelson wrote: > So, I'd argue there's a use case for projects to be explicit about > which versions of other components they rely upon for a given release, > and that there should be a way for CoApp to support that. > If we move towards building, signing and distributing projects on behalf of > their owners, perhaps one of our pre-requisites would be that the project > needs to elicit the exact version of their dependencies that they did all > their release testing/development against. >
I can certainly see the value in that, on one hand... but on the other hand, the last project I was on had a substantial list of third-party library dependencies. The obvious "building block" libraries got pulled in by quite a number of different components - libpng, libxml, MySQL, OpenSSL, and Qt all depend on it. I was also building some of the tools we needed, so that they too would be in the self-contained toolchain, so Subversion, Ruby, Perl, and indeed Python also all had a zlib dependency. For the sake of sanity I explicitly did not want to attempt to deal with multiple versions of these libraries - not least because some of these libraries could get shipped to the customer, potentially over a slow online update. I actually ended up doing quite a fair bit of "extra" work in order to /not/ use the pre-bundled versions - in some cases, it was more or less enforced by the project's Win32 build system, hence why a great lot of my script was running "sed" or some such against build scripts! _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
