multiple drivers, linking problems

Dan Reverri dan at basho.com
Mon Oct 4 15:19:40 EDT 2010


Would it make sense to use a format similar to port_envs to define the
individual so envs?

Daniel Reverri
Developer Advocate
Basho Technologies, Inc.
dan at basho.com


On Mon, Oct 4, 2010 at 11:52 AM, Eric Cestari <eric at ohmforce.com> wrote:

> HI again,
>
> Same objective, building ejabberd with rebar, different problem.
> ejabberd has several C drivers, xml, tls, iconv etc.
>
> In my rebar.config, I have :
> {so_specs,[
>           {"priv/lib/ejabberd_zlib_drv.so", ["c_src/ejabberd_zlib_drv.o"]},
>           {"priv/lib/iconv_erl.so", ["c_src/iconv_erl.o"]},
>           {"priv/lib/stringprep_drv.so", ["c_src/stringprep_drv.o",
>                                       "c_src/uni_data.c",
>                                       "c_src/uni_norm.c"]},
>           {"priv/lib/sha_drv.so", ["c_src/sha_drv.o"]},
>           {"priv/lib/tls_drv.so", ["c_src/tls_drv.o"]},
>           {"priv/lib/xml.so", ["c_src/xml.o"]}
>           ]}.
>
> Which is verbose, but I can stand it. rebar is opiniated towards a modular
> codebase.
> My problem is tls_drv.so (for instance) should be linked to tls and ssl.
> But I cannot express that easily, unless I add to all my drivers all the
> linking information in the build flag options.
>
> So my proposal would be to optionally add a third term ;
>        {"priv/lib/tls_drv.so", ["c_src/tls_drv.o"], {ldflags, "-ltls"}},
>
> or {"priv/lib/tls_drv.so", ["c_src/tls_drv.o", {ldflags, "-ltls"}]}, for
> keeping arity.
>
> What do you think ?
>
> Cheers,
>        Eric
> _______________________________________________
> rebar mailing list
> rebar at lists.basho.com
> http://lists.basho.com/mailman/listinfo/rebar_lists.basho.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/rebar_lists.basho.com/attachments/20101004/dd02ec90/attachment.html>


More information about the rebar mailing list