Time to kick out libpurple.framework?

[Stephen Holt]

I'm conditionally for this.

Having binaries in version control sucks. No one denies that.  But a
few issues need to be resolved, and I'd like to see them working (in a
fork) before we make any changes:

    * We need some way to intelligently mark that libpurple or a
dependency needs updating
        * No way we can keep an Xcode project up to date with
pidgin/glib/gstreamer/etc updates.
        * We need to assure that all developers are working against
the same version of libpurple for a given revision
        * We need to assure that libpurple is not being built more
often than required (no one wants to build a whole framework for a 1
line change in an input filter)

    * We need to assure that checking out a specific historical
revision will build the libpurple that was current as of that
revision.

    * We need a clear and well known process to migrate changes from
im.pidgin.adium to our hg repo.
        * Does this mean maintaining i.p.a out of band and exporting
the code state at that time to out repo?
        * The less human interaction this involves, the better. Make
it scriptable.

That about sums up my conditional support - by far the biggest concern
I have is assuring that developers have the correct version of
libpurple built for a given revision.  And I would really really like
to see this working on a fork before we impliment on tip.

--
Steve Holt

On Tue, Mar 29, 2011 at 11:31 AM, Christopher Forsythe <chris at growl.info> wrote:
>
>
> On Tue, Mar 29, 2011 at 1:27 PM, Christopher Forsythe <chris at growl.info>
> wrote:
>>
>>
>> On Tue, Mar 29, 2011 at 12:35 PM, Alan Humpherys <alangh at adium.im> wrote:
>>>
>>> On Mar 29, 2011, at 11:26 AM, Ryan Govostes wrote:
>>>
>>> > Definitely yes.
>>> >
>>> > I am strongly opposed to the original decision to move binaries to
>>> > trunk. I encountered a number of build errors when the switch occurred, and
>>> > it prevents me from tweaking my compiler and SDK settings as I like, without
>>> > a great deal of work.
>>> >
>>> > Let's move back to source for all of the frameworks, using
>>> > subrepositories. If we can do a read-only mirror of the im.adium.adium
>>> > branch of libpurple to our repo that'd be great.
>>> >
>>> > Ryan
>>>
>>> +1
>>>
>>> I  agree
>>>
>>
>> Once pidgin goes to mercurial, can libpurple be pulled in as just a
>> subrepo and make this even easier?
>
> Oh bah, I reread the original post, and then see mercurial (and get it
> pointed out to me by 2 people right after).
> +1 :)
> Chris