Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Stefan Seefeld]

Steve,

Steve M. Robbins wrote:


It turns out to be simpler than that.  With a small tweak to boost's
Jamroot file, I'm now generating libraries without the toolset and
without the Boost version decorations.  I will use this for the
upcoming Boost 1.35.0 Debian packages.


By all means, could you please get together with other packagers 
(fedora, notably) and try to establish a common procedure ? (Ideally 
this procedure would be christened by boost itself, eventually, but 
unfortunately I just don't see that happening anytime soon.)


This is really a big usability issue for developers who want to develop 
on platforms such as debian or fedora, but still remain as portable as 
possible, as they have to be prepared for lots of subtle and 
not-so-subtle variations, complicating their life unnecessarily. It's 
bad enough that there is no API & ABI stability guarantee from one boost 
version to the next...


Thanks !

Stefan

--

  ...ich hab' noch einen Koffer in Berlin...


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Steve M. Robbins]

On Thu, May 01, 2008 at 10:30:32AM -0400, David Abrahams wrote:
> 
> on Thu Mar 13 2008, "Steve M. Robbins"  wrote:
> 
> > Actually, the only thing about Boost that causes grief to packagers is
> > that the toolset name (e.g. "gcc42") is embedded in the library
> > filename.  I just wrote a response on Boost.Build outlining this in
> > some detail [1].  Embedding the compiler version requires Debian to
> > rebuild all the boost packages each time a compiler change is made.
> > This is unnecessary when the compiler ABI is maintained (e.g 4.1 ->
> > 4.2) and also unnecessary when the ABI is broken, as Debian has
> > another mechanism to handle that.  Note that rebuilding the boost
> > packages has a huge ripple effect, so it is more than simply
> > "unnecessary", it is a very large headache.
> 
> I'm not sure that's the end of the story.  One reason we embed the
> compiler name in the library name is that version-specific workarounds
> often show up in header files.  The result is that when compiled against
> gcc-4.2, client code will effectively see different header contents than
> the precompiled boost library that was built with gcc-4.1 did.

Interesting.  I didn't know that.  Debian's "unstable" distribution
has been using the same compiled Boost libraries with a mix of GCC 4.1
and 4.2 since December.  GCC 4.3 is being added to the mix, too.

I should grep the boost headers for BOOST_WORKAROUND to see what
differences might arise.


> I think we'd need to work out a discipline of avoiding
> BOOST_WORKAROUND code in headers that distinguishes compiler minor
> versions.  I'm not very confident that I've thought that issue
> through completely... is it that simple?

If possible, that would be nice from a library distributor's 
point of view.


> > The fact that Boost embeds the Boost version in the library name is
> > cause for grief to client software authors.  But this is unavoidable
> > as long as Boost doesn't take care to maintain ABI across versions.
> > Fortunately, there is a simple solution to this, which I touch on in
> > my post [1].
> 
> This is just a change to bjam?  Have you gotten any traction with that
> idea?

It turns out to be simpler than that.  With a small tweak to boost's
Jamroot file, I'm now generating libraries without the toolset and
without the Boost version decorations.  I will use this for the
upcoming Boost 1.35.0 Debian packages.

We had a long thread in Boost.Build about this idea [1].  I'm not sure
I convinced anyone to my point of view.  :-)  We'll proceed with
Debian-specific changes for the short term and see how it goes.

Regards,
-Steve

[1] Thread starts at
http://lists.boost.org/boost-build/2008/04/18835.php
The shortest statement of Debian's position is
http://lists.boost.org/boost-build/2008/04/18839.php
(And please ignore http://lists.boost.org/boost-build/2008/04/18918.php
 as I've changed my mind again)


signature.asc
Description: Digital signature

Re: Boost.Python: Build and Install with Python 2.4 and 2.5?

[David Abrahams]

on Thu Mar 13 2008, "Steve M. Robbins"  wrote:

> Actually, the only thing about Boost that causes grief to packagers is
> that the toolset name (e.g. "gcc42") is embedded in the library
> filename.  I just wrote a response on Boost.Build outlining this in
> some detail [1].  Embedding the compiler version requires Debian to
> rebuild all the boost packages each time a compiler change is made.
> This is unnecessary when the compiler ABI is maintained (e.g 4.1 ->
> 4.2) and also unnecessary when the ABI is broken, as Debian has
> another mechanism to handle that.  Note that rebuilding the boost
> packages has a huge ripple effect, so it is more than simply
> "unnecessary", it is a very large headache.

I'm not sure that's the end of the story.  One reason we embed the
compiler name in the library name is that version-specific workarounds
often show up in header files.  The result is that when compiled against
gcc-4.2, client code will effectively see different header contents than
the precompiled boost library that was built with gcc-4.1 did.  I think
we'd need to work out a discipline of avoiding BOOST_WORKAROUND code in
headers that distinguishes compiler minor versions.  I'm not very
confident that I've thought that issue through completely... is it that
simple?

> The fact that Boost embeds the Boost version in the library name is
> cause for grief to client software authors.  But this is unavoidable
> as long as Boost doesn't take care to maintain ABI across versions.
> Fortunately, there is a simple solution to this, which I touch on in
> my post [1].

This is just a change to bjam?  Have you gotten any traction with that
idea?

-- 
Dave Abrahams
Boost Consulting
http://boost-consulting.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Boost.Python: Build and Install with Python 2.4 and 2.5?

[David Abrahams]

on Sat Feb 23 2008, "Steve M. Robbins"  wrote:

> Hi,
>
> I'm part of the Debian Boost packaging team, seeking some guidance on
> how to build and install Boost.Python so that it is usable with all
> Python versions shipped in Debian.  Debian currently ships Python 2.4
> and 2.5.
>
> When reading the following, keep in mind that Boost.Python is not a
> Python extension but, rather, a library that eases writing an
> extension in C++.  So it is necessary that the compiled libraries be
> visible to be linked with user-written C++ code.
>
>
> One idea is to use a user-config.jam file containing
>
>   using python : 2.4 : /usr ;
>   using python : 2.5 : /usr ;
>
> Then run jam twice
>
>   bjam variant= ...
>   bjam variant= ... python python=2.5

Well, you can run it once:

  bjam python=2.4,2.5

IIRC.

> This produces pairs of library files such as
>
>   bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a
>   bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a
>
> (and similar pairs for shared libraries and all other variants).
>
> The key item to note is that the two files have the same name.  The
> python version, unlike the GCC version, is not embedded in the library
> name.  So these files cannot both be installed into /usr/lib.

I don't know how such name gristing is generated in Boost.Build, but IMO
we should change the naming to account for the Python version.  This is
really a question for the Boost.Build list, I think.

> The question, then, is how to distinguish them once installed?  
> Should we:
>
>
> 1. Rename the resulting libraries to decorate them with the python
> version in addition to the gcc version?  This could generate
>
>   libboost_python-py24-gcc42-1_34_1.a
>   libboost_python-py25-gcc42-1_34_1.a

I'm not an expert in this area, but it's been my understanding that
simply renaming library files doesn't work for some reason.

>
> 2. Similar to above, but use bjam's --buildid option?  This has the
> drawback that the build ID shows up differently than the GCC version
> decoration, e.g.
>
>   libboost_python-gcc42-1_34_1-py24.a
>   libboost_python-gcc42-1_34_1-py25.a

Sounds more likely to work, even though it's ugly.

> 3. Put the libraries in different subdirectories, e.g.
>
>   /usr/lib/python2.4/libboost_python-gcc42-1_34_1.a
>   /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a

You could do that, and then provide symlinks with the python version
grist in /usr/lib
>
>
> 4. Put the default version directly in /usr/lib and the others
> in subdirectories, e.g.
>
>   /usr/lib/libboost_python-gcc42-1_34_1.a
>   /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a
>
>
> The drawback to all these approaches is that client code has to be
> adjusted to build on Debian.  Linking against Boost (for non-bjam
> projects) is already hard enough with the decorated library names that
> I fear making the situation worse.  

Understandable.

> The attraction of #4 is that at least the variants for the default
> python version are found in a natural manner.  This has some appeal to
> me, personally, but I worry that it is too easy to build an extension
> to python 2.5 and link in the wrong Boost.Python library.  In
> contrast, the other options have the advantage that it forces the user
> to declare which version of Python is being used.
>
> I'd appreciate your thoughts.  Have I overlooked a better solution?
> What are the other packagers of Boost.Python doing?  

Unfortunately, we don't tend to get a lot of interaction with packagers
around here, so we don't tend to know what they're doing.  I think Boost
raises more packaging issues than most other libraries, so it would be
good to have more involvement from y'all.

> In principle, it would be nice to have the Boost libraries named the
> same across distributions.

No doubt!

-- 
Dave Abrahams
Boost Consulting
http://boost-consulting.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Steve M. Robbins]

On Wed, Mar 12, 2008 at 09:11:25PM -0400, David Abrahams wrote:
> 
> on Sat Feb 23 2008, "Steve M. Robbins"  wrote:

[...]

> > This produces pairs of library files such as
> >
> > bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a
> > bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a
> >
> > (and similar pairs for shared libraries and all other variants).
> >
> > The key item to note is that the two files have the same name.  The
> > python version, unlike the GCC version, is not embedded in the library
> > name.  So these files cannot both be installed into /usr/lib.
> 
> I don't know how such name gristing is generated in Boost.Build, but IMO
> we should change the naming to account for the Python version.

Perhaps.  For the moment, I can get the desired effect using
--buildid.


> > The question, then, is how to distinguish them once installed?  
> > Should we:
> >
> >
> > 1. Rename the resulting libraries to decorate them with the python
> > version in addition to the gcc version?  This could generate
> >
> > libboost_python-py24-gcc42-1_34_1.a
> > libboost_python-py25-gcc42-1_34_1.a
> 
> I'm not an expert in this area, but it's been my understanding that
> simply renaming library files doesn't work for some reason.

Partly true.  I believe you can rename the static libs (.a files) at
will.  The problem lies in the shared libs.  Subsequent to writing the
above, I discovered that the two shared libraries (.so.*) have exactly
the same SONAME, so renaming doesn't work for them.


> > 2. Similar to above, but use bjam's --buildid option?  This has the
> > drawback that the build ID shows up differently than the GCC version
> > decoration, e.g.
> >
> > libboost_python-gcc42-1_34_1-py24.a
> > libboost_python-gcc42-1_34_1-py25.a
> 
> Sounds more likely to work, even though it's ugly.

Yes, this works because the --buildid is incorporated into the
SONAMEs, thus distinguishing them.  Using --buildid is therefore the
*only* solution short of hacking the soname generation myself.



> > I'd appreciate your thoughts.  Have I overlooked a better solution?
> > What are the other packagers of Boost.Python doing?  
> 
> Unfortunately, we don't tend to get a lot of interaction with packagers
> around here, so we don't tend to know what they're doing.  I think Boost
> raises more packaging issues than most other libraries, so it would be
> good to have more involvement from y'all.

Actually, the only thing about Boost that causes grief to packagers is
that the toolset name (e.g. "gcc42") is embedded in the library
filename.  I just wrote a response on Boost.Build outlining this in
some detail [1].  Embedding the compiler version requires Debian to
rebuild all the boost packages each time a compiler change is made.
This is unnecessary when the compiler ABI is maintained (e.g 4.1 ->
4.2) and also unnecessary when the ABI is broken, as Debian has
another mechanism to handle that.  Note that rebuilding the boost
packages has a huge ripple effect, so it is more than simply
"unnecessary", it is a very large headache.

The fact that Boost embeds the Boost version in the library name is
cause for grief to client software authors.  But this is unavoidable
as long as Boost doesn't take care to maintain ABI across versions.
Fortunately, there is a simple solution to this, which I touch on in
my post [1].

Regards,
-Steve

[1] http://lists.boost.org/boost-build/2008/03/18565.php


signature.asc
Description: Digital signature

Re: [pkg-boost-devel] [boost] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Steve M. Robbins]

On Wed, Feb 27, 2008 at 08:43:43AM -0500, Stefan Seefeld wrote:

> (I still don't see the problem: Source packages don't depend on binary  
> packages, only binary packages do. 

Source packages *do*, in fact, depend on binary packages.  Each source
package describes exactly the packages required to build the source;
e.g. whether Qt3 libraries or X11 libraries are needed.  These are
called "build-time dependencies" or "build-deps" for short.


> And if you package your extension module you are in control of what
> python version(s) you build against, no ?)

That's a true statement.  

Several extension modules will, in fact, build for both Python 2.4 and
2.5.  Now imagine an extension module that uses Boost.Python.  As
mentioned, it must have the relevant build-deps.  To support this, the
relevant boost-python development packages must be co-installable
(i.e. not conflict with each other).

It's not yet clear to me whether this is an achievable goal, but it
would be nice.

Regards,
-Steve


signature.asc
Description: Digital signature

Re: [pkg-boost-devel] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Josselin Mouette]

Le mardi 26 février 2008 à 22:04 -0600, Steve M. Robbins a écrit :
> The idea is to create a single -dev package that contains the
> following in /usr/lib:
> 
> libboost_python-py24-gcc42-1_34_1.so
> libboost_python-py24-gcc42-1_34_1.a
> 
> libboost_python-py25-gcc42-1_34_1.so
> libboost_python-py25-gcc42-1_34_1.a
> 
> The -dev package contains an rtupdate script to create the following
> symlinks (also in /usr/lib):
> 
> libboost_python-gcc42-1_34_1.so
> libboost_python-gcc42-1_34_1.a
> 
> Does that sound right?

Yes.

> This has the advantage that a Python extension can be build and
> packaged for either or both supported Python versions, albeit at the
> cost of changing the link line.  Code that just needs the default
> version can use the undecorated form in the link line.  The
> disadvantage is that if you use the undecorated form, you're not quite
> sure what version of Boost.Python is linked in.

This sounds good as this way, extensions using boost can be made to
build with all available python versions.

It would be nice to have libboost_python2.4.so and libboost_python2.5.so
symbolic links as well, so that building an extension for all available
python versions doesn’t require setting the GCC version and boost
version in the link line.
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: [pkg-boost-devel] [boost] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Stefan Seefeld]

Steve M. Robbins wrote:

On Tue, Feb 26, 2008 at 11:15:24PM -0500, Stefan Seefeld wrote:

Steve M. Robbins wrote:

Hi,

Thanks to Steve, Bernd, and Josselin for ideas.


On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:


Decorate only the shared library names with the python versions, and retain
the current names for the .a files and .so symlinks - with two separate -dev
packages that conflict with one another?

That still prevents anyone from packaging an extension that builds for both
python2.4 and python2.5 at once using Boost.Python, but I think it solves
all the other drawbacks of the other solutions you suggested.

Indeed.  Do you think this is a serious restriction?  Given that
Debian likes to package extensions for all python versions, I tend to
think it will become a problem.
extensions for different python installations don't conflict because 
they end up in separate directories. 


The proposal above is that we provide a boost-python-2.4-dev and a
boost-python-2.5-dev package that conflict with one another (because
they would contain files of the same name).  This prevents a source
package from depending on both for a build, and therefore a source
package for a Python extension cannot produce an extension for each
Python version.


How does this work for source packages using Python-dev directly ? Don't 
they face the same problem ?


(I still don't see the problem: Source packages don't depend on binary 
packages, only binary packages do. And if you package your extension 
module you are in control of what python version(s) you build against, no ?)


Regards,
Stefan


--

  ...ich hab' noch einen Koffer in Berlin...


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [boost] [pkg-boost-devel] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Domenico Andreoli]

Hi,

On Tue, Feb 26, 2008 at 10:04:26PM -0600, Steve M. Robbins wrote:
>
> On Mon, Feb 25, 2008 at 01:15:31PM +0100, Josselin Mouette wrote:
> > 
> > The solution is to keep the names decorated with both python versions,
> > but to maintain a farm of symbolic links pointing to the current python
> > version. As Steve noted, you don???t need one for the runtime libs, but
> > for the .a and the .so symlink that are used at build time, this is
> > required.
> 
> OK, both you and Bernd suggested rtupdate.  Bernd even pointed me to a
> description of it [1]; thanks.  Let me see if I understand your
> proposal.
> 
> The idea is to create a single -dev package that contains the
> following in /usr/lib:
> 
> libboost_python-py24-gcc42-1_34_1.so
> libboost_python-py24-gcc42-1_34_1.a
> 
> libboost_python-py25-gcc42-1_34_1.so
> libboost_python-py25-gcc42-1_34_1.a
> 
> The -dev package contains an rtupdate script to create the following
> symlinks (also in /usr/lib):
> 
> libboost_python-gcc42-1_34_1.so
> libboost_python-gcc42-1_34_1.a
> 
> Does that sound right?

It may sound even better if multiple Boost versions were considered,
packaging them in versioned source packages (ie boost-1.34.1,
boost-1.35.0). Respective -dev packages should then be also versioned
and conflicting each other, as the mostly undecorated symlinks there
provided. Having boost-defaults driving the default Boost and Python
versions and the completely undecorated symlinks.

This, for instance, would allow Boost 1.35.0 in lenny while 1.34.1
being the default one. I frankly doubt a full transition to 1.35.0
would happen before the release of lenny.

Ciao,
Domenico

-[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [pkg-boost-devel] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Steve Langasek]

On Tue, Feb 26, 2008 at 10:04:26PM -0600, Steve M. Robbins wrote:
> On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:

> > Decorate only the shared library names with the python versions, and retain
> > the current names for the .a files and .so symlinks - with two separate -dev
> > packages that conflict with one another?

> > That still prevents anyone from packaging an extension that builds for both
> > python2.4 and python2.5 at once using Boost.Python, but I think it solves
> > all the other drawbacks of the other solutions you suggested.

> Indeed.  Do you think this is a serious restriction?  Given that
> Debian likes to package extensions for all python versions, I tend to
> think it will become a problem.

I think it's a tolerable restriction.  Clearly there are no packages using
Boost.Python today to build for more than one version of python, so it's of
course not a regression in any case; and we don't *need* all python
extensions to be built for all python versions, it just makes transitions
easier the more there are.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [pkg-boost-devel] [boost] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Steve M. Robbins]

On Tue, Feb 26, 2008 at 11:15:24PM -0500, Stefan Seefeld wrote:
> Steve M. Robbins wrote:
> > Hi,
> > 
> > Thanks to Steve, Bernd, and Josselin for ideas.
> > 
> > 
> > On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:
> > 
> >> Decorate only the shared library names with the python versions, and retain
> >> the current names for the .a files and .so symlinks - with two separate 
> >> -dev
> >> packages that conflict with one another?
> >>
> >> That still prevents anyone from packaging an extension that builds for both
> >> python2.4 and python2.5 at once using Boost.Python, but I think it solves
> >> all the other drawbacks of the other solutions you suggested.
> > 
> > Indeed.  Do you think this is a serious restriction?  Given that
> > Debian likes to package extensions for all python versions, I tend to
> > think it will become a problem.
> 
> extensions for different python installations don't conflict because 
> they end up in separate directories. 

The proposal above is that we provide a boost-python-2.4-dev and a
boost-python-2.5-dev package that conflict with one another (because
they would contain files of the same name).  This prevents a source
package from depending on both for a build, and therefore a source
package for a Python extension cannot produce an extension for each
Python version.


-Steve


signature.asc
Description: Digital signature

Re: [boost] [pkg-boost-devel] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Stefan Seefeld]

Steve M. Robbins wrote:

Hi,

Thanks to Steve, Bernd, and Josselin for ideas.


On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:


Decorate only the shared library names with the python versions, and retain
the current names for the .a files and .so symlinks - with two separate -dev
packages that conflict with one another?

That still prevents anyone from packaging an extension that builds for both
python2.4 and python2.5 at once using Boost.Python, but I think it solves
all the other drawbacks of the other solutions you suggested.


Indeed.  Do you think this is a serious restriction?  Given that
Debian likes to package extensions for all python versions, I tend to
think it will become a problem.


extensions for different python installations don't conflict because 
they end up in separate directories. Python's own runtime library does a 
similar thing: it is installed in /lib/python/config.


What if boost.python gets installed into that directory, too ? Wouldn't 
this solve the issue ?


Regards,
Stefan

--

  ...ich hab' noch einen Koffer in Berlin...


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [pkg-boost-devel] Boost.Python: Build and Install with Python 2.4 and 2.5?

[Steve M. Robbins]

Hi,

Thanks to Steve, Bernd, and Josselin for ideas.


On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:

> Decorate only the shared library names with the python versions, and retain
> the current names for the .a files and .so symlinks - with two separate -dev
> packages that conflict with one another?
> 
> That still prevents anyone from packaging an extension that builds for both
> python2.4 and python2.5 at once using Boost.Python, but I think it solves
> all the other drawbacks of the other solutions you suggested.

Indeed.  Do you think this is a serious restriction?  Given that
Debian likes to package extensions for all python versions, I tend to
think it will become a problem.


On Mon, Feb 25, 2008 at 01:15:31PM +0100, Josselin Mouette wrote:
> Hi,
> 
> Le samedi 23 février 2008 à 22:45 -0600, Steve M. Robbins a écrit :

> > 1. Rename the resulting libraries to decorate them with the python
> > version in addition to the gcc version?  This could generate
> > 
> > libboost_python-py24-gcc42-1_34_1.a
> > libboost_python-py25-gcc42-1_34_1.a
> 
> I think this is fine.

[ ... ]

> The solution is to keep the names decorated with both python versions,
> but to maintain a farm of symbolic links pointing to the current python
> version. As Steve noted, you don???t need one for the runtime libs, but
> for the .a and the .so symlink that are used at build time, this is
> required.

OK, both you and Bernd suggested rtupdate.  Bernd even pointed me to a
description of it [1]; thanks.  Let me see if I understand your
proposal.

The idea is to create a single -dev package that contains the
following in /usr/lib:

libboost_python-py24-gcc42-1_34_1.so
libboost_python-py24-gcc42-1_34_1.a

libboost_python-py25-gcc42-1_34_1.so
libboost_python-py25-gcc42-1_34_1.a

The -dev package contains an rtupdate script to create the following
symlinks (also in /usr/lib):

libboost_python-gcc42-1_34_1.so
libboost_python-gcc42-1_34_1.a

Does that sound right?

This has the advantage that a Python extension can be build and
packaged for either or both supported Python versions, albeit at the
cost of changing the link line.  Code that just needs the default
version can use the undecorated form in the link line.  The
disadvantage is that if you use the undecorated form, you're not quite
sure what version of Boost.Python is linked in.


-Steve

[1] http://people.debian.org/~srivasta/manoj-policy/x673.html


signature.asc
Description: Digital signature

Re: Boost.Python: Build and Install with Python 2.4 and 2.5?

[Josselin Mouette]

Hi,

Le samedi 23 février 2008 à 22:45 -0600, Steve M. Robbins a écrit :
> One idea is to use a user-config.jam file containing
> 
>   using python : 2.4 : /usr ;
>   using python : 2.5 : /usr ;
> 
> Then run jam twice
> 
>   bjam variant= ...
>   bjam variant= ... python python=2.5
> 
> This produces pairs of library files such as
> 
>   bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a
>   bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a

First of all, I think you need the configuration to be symmetric, not to
have a "default" build and a "python2.5" one. You need to build things
for python2.4, the same for python2.5 (for all of `pyversions -r`,
actually), and handle the default version afterwards. Otherwise you’ll
need to adapt your build each time the list of supported python versions
changes.

> 1. Rename the resulting libraries to decorate them with the python
> version in addition to the gcc version?  This could generate
> 
>   libboost_python-py24-gcc42-1_34_1.a
>   libboost_python-py25-gcc42-1_34_1.a

I think this is fine.

> 3. Put the libraries in different subdirectories, e.g.
> 
>   /usr/lib/python2.4/libboost_python-gcc42-1_34_1.a
>   /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a

Fine too, but please don’t name the directories like this!

> 4. Put the default version directly in /usr/lib and the others
> in subdirectories, e.g.
> 
>   /usr/lib/libboost_python-gcc42-1_34_1.a
>   /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a

No, for the reason explained above.

> The drawback to all these approaches is that client code has to be
> adjusted to build on Debian.  Linking against Boost (for non-bjam
> projects) is already hard enough with the decorated library names that
> I fear making the situation worse.  

The solution is to keep the names decorated with both python versions,
but to maintain a farm of symbolic links pointing to the current python
version. As Steve noted, you don’t need one for the runtime libs, but
for the .a and the .so symlink that are used at build time, this is
required.

You can have a look at e.g. python-gnome2.rtupdate for a simple example
of how to do this.

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Boost.Python: Build and Install with Python 2.4 and 2.5?

[Bernd Zeimetz]

Hi,

I'd suggest to do

> 3. Put the libraries in different subdirectories, e.g.
> 
>   /usr/lib/python2.4/libboost_python-gcc42-1_34_1.a
>   /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a

and add a symlink to /usr/lib which points to the library version for
the current default python version. You could use rtupdate to handle
the symlink, so there's no need to rebuild the package when the default
Python version is changed.


Cheers,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Boost.Python: Build and Install with Python 2.4 and 2.5?

[Steve Langasek]

On Sat, Feb 23, 2008 at 10:45:18PM -0600, Steve M. Robbins wrote:

> The question, then, is how to distinguish them once installed?  

> Should we:

[...]

> The drawback to all these approaches is that client code has to be
> adjusted to build on Debian.

Decorate only the shared library names with the python versions, and retain
the current names for the .a files and .so symlinks - with two separate -dev
packages that conflict with one another?

That still prevents anyone from packaging an extension that builds for both
python2.4 and python2.5 at once using Boost.Python, but I think it solves
all the other drawbacks of the other solutions you suggested.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Boost.Python: Build and Install with Python 2.4 and 2.5?

[Steve M. Robbins]

Hi,

I'm part of the Debian Boost packaging team, seeking some guidance on
how to build and install Boost.Python so that it is usable with all
Python versions shipped in Debian.  Debian currently ships Python 2.4
and 2.5.

When reading the following, keep in mind that Boost.Python is not a
Python extension but, rather, a library that eases writing an
extension in C++.  So it is necessary that the compiled libraries be
visible to be linked with user-written C++ code.


One idea is to use a user-config.jam file containing

using python : 2.4 : /usr ;
using python : 2.5 : /usr ;

Then run jam twice

bjam variant= ...
bjam variant= ... python python=2.5

This produces pairs of library files such as

bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a
bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a

(and similar pairs for shared libraries and all other variants).

The key item to note is that the two files have the same name.  The
python version, unlike the GCC version, is not embedded in the library
name.  So these files cannot both be installed into /usr/lib.

The question, then, is how to distinguish them once installed?  
Should we:


1. Rename the resulting libraries to decorate them with the python
version in addition to the gcc version?  This could generate

libboost_python-py24-gcc42-1_34_1.a
libboost_python-py25-gcc42-1_34_1.a


2. Similar to above, but use bjam's --buildid option?  This has the
drawback that the build ID shows up differently than the GCC version
decoration, e.g.

libboost_python-gcc42-1_34_1-py24.a
libboost_python-gcc42-1_34_1-py25.a


3. Put the libraries in different subdirectories, e.g.

/usr/lib/python2.4/libboost_python-gcc42-1_34_1.a
/usr/lib/python2.5/libboost_python-gcc42-1_34_1.a


4. Put the default version directly in /usr/lib and the others
in subdirectories, e.g.

/usr/lib/libboost_python-gcc42-1_34_1.a
/usr/lib/python2.5/libboost_python-gcc42-1_34_1.a


The drawback to all these approaches is that client code has to be
adjusted to build on Debian.  Linking against Boost (for non-bjam
projects) is already hard enough with the decorated library names that
I fear making the situation worse.  

The attraction of #4 is that at least the variants for the default
python version are found in a natural manner.  This has some appeal to
me, personally, but I worry that it is too easy to build an extension
to python 2.5 and link in the wrong Boost.Python library.  In
contrast, the other options have the advantage that it forces the user
to declare which version of Python is being used.

I'd appreciate your thoughts.  Have I overlooked a better solution?
What are the other packagers of Boost.Python doing?  In principle,
it would be nice to have the Boost libraries named the same across
distributions. 

Thanks,
-Steve


signature.asc
Description: Digital signature