On Dec 24, 2010, at 5:19 PM, Ryan Govostes wrote: > > 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.
subrepos are awesome. My limited use of them has been great. > 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. -1 (assuming my voice counts, anyway). We actually moved to shell scripts rather than Xcode projects for libpurple because it had been monumental pain to keep the xcodeproj in sync with upstream libpurple changes. If you want xcode to call the shell script to produce the frameworks, that sounds like a good idea (I'd be +1 on that, I'm surprised we don't do that now. Perian has build steps along these lines, so maybe you can crib from its setup?), but I'd strongly caution against making xcodeproj's for traditional ./configure && make based software like pidgin and its dependencies. As a semi-related aside, I'm working on getting an hg conversion of pidgin working, so maybe some day it'll be possible to have pidgin sources come in as a subrepo as well. Augie > > 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 <r...@adium.im> wrote: >> >>> I note that /Frameworks is full of binaries. Why is this so? >>> >>> http://hg.adium.im/adium/file/5b2e819a13f8/Frameworks >>> >>> -- Ryan >>> >> > >
