Binaries in trunk

[Ryan Govostes]

I was hoping the new libpurple build scripts I wrote would put us down the path of having the build processes more tightly coupled, rather than this. (Not to mention, this drew my attention when Adium failed to build due of one of the prebuilt frameworks.)

Mercurial supports subrepositories [1], so one suggestion is to make two repositories; one for binaries and one that actually is the libpurple source. By default we could use the binaries repo for people who just want to compile Adium, and then if you are interested in building from source that could be done by switching the .hgsub file.

Eventually we could move libpurple et al into Xcode build systems, at first just using an external build step to run make. Then at least we could build everything in one pass rather than separately.

Ryan

1: http://mercurial.selenic.com/wiki/Subrepository

On Dec 23, 2010, at 10:39 PM, Stephen Holt wrote:

> The reason, at least as far as I understand it, is that the libpurple build is incredibly cumbersome. It requires a multitude of source tarball downloads (plus yet another DVCS tool fir pidgin's repository) and a significant amount of compile time.
> 
> It is possible to accomplish this with a script in a build step, but keeping the binaries up to date when the source updates (Xcode will not track source file mod times for this) and the amount of time it takes to compile libpurple+dependencies are the key drawbacks, in my recollection.
> 
> We know its ugly, and id love to see this situation improve. But for now, versioned binaries of libpurple+dependencies seems the most pragmatic path for us.
> 
> --
> Steve Holt
> 
> Sent from my iPhone
> 
> On Dec 23, 2010, at 8:50 PM, Ryan Govostes <ryan at adium.im> wrote:
> 
>> I note that /Frameworks is full of binaries. Why is this so?
>> 
>> http://hg.adium.im/adium/file/5b2e819a13f8/Frameworks
>> 
>> -- Ryan
>> 
>