Time to kick out libpurple.framework?

[Colin Barrett]

Is it worth investigating starting a fresh repository for 1.6 (yet again), if we implement this?

It would mean we would lose the easy merging and branching you get when you have two versions in the same repo, but new developer approachability would go *way* up if repository size went down. I think it may be a worthwhile tradeoff, but I wonder what other folks think as well. I also wonder what the Mercurial roadmap for trimmed history clones looks like. Perhaps Augie can advise on that?

My first pass, strawman take on this is that if we can eliminate *all* binary dependencies, it is worth doing. I don't know how feasible that is.

-Colin

On Mar 29, 2011, at 10:04 AM, Thijs Alkemade wrote:

> Hey all,
> 
> For those that might have missed it, yesterday some commits where done for to move everything to 10.6 and drop PPC. After that to that, Adrian moved all XCode targets to clang-llvm. The results of these changes are quite impressive: the latest nightly built in 4 minutes, compared to just over 8 for the last nightly before dropping 10.5.
> 
> I, on the other hand, was busy changing all pre-built dependencies to 10.6 and remove PPC. I messed something up, so I had to commit Frameworks/libpurple.framework/Versions/0.7.11/libpurple twice. Oops. Sorry all for that extra 10MB in all your repositories.
> 
> In fact, .hg is around 450MB now. Of which:
> 
> 207M	.hg/store/data/_frameworks/libpurple.framework
> 
> Yes, by now almost half the data a new developer downloads is old versions of libpurple which they will probably never even glance at.
> 
> So, as on the one hand build times have halved, and on the other hand our repository is exploding in size, I think it really should be considered to move the libpurple sources into the tree instead of the binary framework (just libpurple, not GStreamer, GLib, etc, as those aren't updated nearly as often).
> 
> It will probably take some work to modify the build scripts to work this way, especially to get it to play nice with XCode. But that is effort that will have to be done anyway. When (I hope it's "when", not "if") Pidgin moves to Mercurial, it would be great to include it as a subrepository, which means building it in the same manner.
> 
> Also, it would be easier to debug problems that go through libpurple code, easier to spot problems with a build (it wouldn't be the first time a binary frameworks turns out to be missing one or more architectures...). 
> 
> I've used the build scripts quite a lot recently, so I don't mind doing all the work for this myself. But I wasn't around when the decision was made to do it this way, so maybe I'm completely missing some problems with it.
> 
> Regards,
> Thijs