[C++-sig] packaging and distribution

[Leonardo Rochael Almeida]

On Tue, 2002-08-20 at 14:06, Rene Rivera wrote:
> [2002-08-20] Leonardo Rochael Almeida wrote:
> 
> >I was looking for a way to move stuff around after boost.build builds them,
> and
> >so I found the 'stage' rule for bjam. However, I didn't find a way to
> >reference a built extension module.
> >
> >[...]
> >
> >So, when I use an 'extension someextension' rule, how do I reference the
> >resulting someextension.so file in a 'stage' rule? I tried
> >'<extension>someextension', but this doesn't seem to work.
> 
> Try: <pyd>someextension -- It should/might work as "PYD" is what python.jam
> uses for building the extensions.

Thanks! that did work.

> [...]
> 
> >Maybe what I really need is to know how to integrate boost.build with
> >distutils...
> 
> To "integrate" it you'd have to do a two step process. First using "stage"
> to move the file to someplace within the build hierarchy... and then
> writting your own distutils scripts to "install" the files.

That's what I had in mind.

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).

To make this less abstract, lemme show part of my Jamfile:

>>>
# Declare a Python extension called dummy
extension dummy
:  # sources
   dummy.cpp

   # dependencies
   <dll>../build/boost_python
  ;

stage deploy/site-packages
:  # move extensions to site-packages
   <pyd>dummy ;

stage deploy/lib
:  # move dlls to lib
   <dll>../build/boost_python ;
<<<

this generates the following tree under deploy:

deploy/
   site-packages/
      dummy.so
   lib/
      libboost_python.so

however:

$ ldd deploy/site-packages/dummy.so
	(...)
        libboost_python.so.1.28.0 => not found
        (...)

the fact that it was not found is not important, but the fact that it's
expecting a version number in the .so name, when no such file was
generated, is. What I don't get is why the <dll> target used in the
'extension' dependency generates an extension that depends in a
versioned .so name while the same target in the 'stage' dependency
doesn't create/copy a .so with the versioned name.

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

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.

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/

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.