on Thu Mar 13 2008, Steve M. Robbins steve-AT-sumost.ca 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
On Thu, May 01, 2008 at 10:30:32AM -0400, David Abrahams wrote:
on Thu Mar 13 2008, Steve M. Robbins steve-AT-sumost.ca 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
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
On Wed, Mar 12, 2008 at 09:11:25PM -0400, David Abrahams wrote:
on Sat Feb 23 2008, Steve M. Robbins steve-AT-sumost.ca wrote:
[...]
This produces pairs of library files such as
bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a
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
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
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
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
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
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
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
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
12 matches
Mail list logo
