coapp-developers team mailing list archive

[Gordon Schumacher <whiplash@xxxxxxxxx>]

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!