[Adium-devl] Libpurple Build Dependencies

[Eric Richie]

On 9/28/07 2:19 PM, "Augie Fackler" <lists at durin42.com> wrote:

> 
> On Sep 28, 2007, at 2:12 PM, Evan Schoenberg wrote:
> 
>> Quoting Eric Richie <edr1084 at gmail.com>:
>> 
>>> On 9/28/07 6:57 AM, "Evan Schoenberg" <evan.s at dreskin.net> wrote:
>>> 
>>>> The updated-build-dependencies at [492] builds without errors for
>>>> me on 10.5,
>>>> FYI.
>>>> 
>>> O_o ...  Ummm... Were you just using the libpurple target to test
>>> that?  I¹m
>>> hoping so because if not it means that my version has somehow gone
>>> nutsy.  I
>>> haven¹t yet copied the new targets into the libpurple build
>>> target.  I
>>> wanted to get them building on their own before I did so.  I
>>> probably should
>>> have mentioned that.  As of my last commit you actually need to
>>> select the
>>> individual lib¹s target to test it.  Sorry for the confusion.
>> 
>> Oh.  Yeah, I just typed make, which builds the libpurple target in
>> Deployment.  I didn't know a target switch was needed :)
>> 
>> Rather than struggling with hacking together compilation within XCode,
>> IMO it'd probably be better to get Augie to help make the process
>> Right as much as possible, the Perian way.  For those who don't know:
>> Perian has an xcode target for each dependency which utilizes its own
>> configure/build process to produce a universal binary against which
>> the final product can link.  This will likely be more complicated for
>> Libpurple.framework since there are multiple steps of dependency (e.g.
>> some of the libraries are dependencies for the dependencies
>> themselves, not for libpurple directly) but results in a much more
>> stable and robust build system.   Some libraries will -need- this
>> because they have compilation steps xcode can't handle cleanly; none
>> of the current ones do, but a faint memory suggests that gstreamer
>> might.
> 
> We should be able to do this all using the native build system for
> each target and some clever linker options. Should I make my goal a
> universal gstreamer binary and just do deps for that first? Or do you
> have libs that Libpurple.framework uses I should do first?

A universal gstreamer binary would be awesome (even if just to aid with our
development).  As far as the rest, I was looking to just go ahead and set up
the build processes that we would need once we have a working product ready
to ship to users so that we'll have that part ready when the time comes.  So
if a gstreamer UB will do that for us then by all means. :)  David had asked
about gettext and glib for immediate use in trunk so if you work on them I'd
definitely make those the first priority and then merge them upstream before
going on to the rest of the gstreamer stuff.  Although they're required
anyway so it shouldn't be much trouble.

> 
>> 
>> The current process utilizes a static config.h for each dependency,
>> made using that library's configure script followed by manual changes
>> to allow for big/small endian appropriateness and other ppc vs. intel
>> #define differences.  An XCode target then includes each file to be
>> built into the library.  Static libraries are produced and linked
>> against as needed.
> 
> aaand a kitten dies because of how nasty that is. Static config.h's
> for the lose. Ideally, upstream rearrangements of code shouldn't
> require project changes on our end.

I have no sympathy for those kittens, I'm sure they deserved it!

-Eric