[C++-sig] packaging and distribution

[David Abrahams]

From: "Leonardo Rochael Almeida" <leo at hiper.com.br>

> Now I have another problem though. The extension module is being created
> with a dll dependency on libboost_python.so.1.28.0, but the boost rule
> 'dll boost_python' (and the boost target '<dll>boost_python generages')
> generates only libboost_python.so, with no reference to the version
> number.
>
> I can manually solve this problem with a symlink, but I don't think I
> should be doing this in jam rules. I think boost.build should be doing
> it the other way around, creating libboost_python.so.1.28.0, or else
> making the extension module depend on the unversioned dll (probably a
> bad idea).

<snip>

> So, how do you guys suggest I deal with that?

I'll have to leave those answers to Rene; I think there's a pretty simple
answer, but he wrote all the SOVERSION stuff...

> Is it a boost v1 problem only? I'm using v1 just because it's the
> released version and (it seems to me) has more complete docs.

Not really, Boost.Python v1 and v2 use basically the same strategy for
building.
However, if you haven't got very far into v1 I'd like to strongly suggest
you try using v2.
The docs, though not yet complete, are probably better and more complete in
the formal sense than those for v1. Though there's no tutorial section,
there's a lot of reference documentation which covers most of the important
stuff. Also, v1 is going to be retired (very) soon. Furthermore, v2 is just
better in nearly every way. One major problem with v1 is that it won't
build on conforming compilers.

> For the curious, I'm using boost.python to make the bindings to a
> largish C++ GIS library that was released recently:
>
> http://www.terralib.org/

Wow, I bet Beman would be curious about that. His background is in mapping
software.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com