Re: Compiling external lib
| From: | JJ | Date: | Fri, 10 Aug 2012 19:05:04 +0000 |
| Subject: | Re: Compiling external lib | ||
| References: | 1 2 3 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-9687@lists.php.net to get a copy of this message | ||
Just a quick update - I cut 1.0.1 which explains how to compile
libavro outside of PECL.
- JJ
On Tue, Aug 7, 2012 at 8:10 AM, JJ <jawed@php.net> wrote:
> Thx guys - this is what I was thinking too. I also think the best
> approach here is to remove the bundled lib and provide detailed
> instructions on how to get libavro installed before the PECL install.
>
> I'll continue working w/distros to get libavro into their repos.
>
> - JJ
>
> On Tue, Aug 7, 2012 at 7:19 AM, Johannes Schlüter
> <johannes@schlueters.de> wrote:
>> On Tue, 2012-08-07 at 05:35 -0700, JJ wrote:
>>> Hey guys - I'd like to get some help with libavro in
>>> http://pecl.php.net/package/xcommerce - the package
>>> configuration
>>> depends on libavro and it errors out with instructions on how to
>>> install the bundled libavro.
>>>
>>> It's a bit tricky because libavro is scarce. I've only found an Ubuntu
>>> pkg for it and even that was in a PPA.
>>>
>>> To make matters more complex, the build of libavro requires cmake.
>>>
>>> Is there a proper way to automatically build libavro as part of the
>>> PECL install? If not, I may bite the bullet and provide full
>>> instructions on how to build libavro outside of PECL.
>>
>> Well, in the end it doesn't matter if they use cmake or a hand written
>> build system or what else. In the end you want to compile those files
>> and link it all together.
>>
>> So you might try to figure out whether
>> a) that lib requires some config file (config.h or such) and whether you
>> generate it using either predefined values or by using the PHP build
>> system
>> b) whether the lib requires special CFLAGS (run make VERBOSE=1 with a
>> cmake build and look at the flags being used)
>>
>> once that information is gathered you can list the avro files in
>> config.[m4|w32] and be done.In a few cases there might be things which
>> need a patch, though.
>>
>> In general I'm no big fan of bundling libraries. that should only be
>> done if it is complicated to get otherwise or changes the behavior too
>> often. Linking against a library provided externally simplifies access
>> to bug fixes in the lib itself.
>>
>> johannes
>>