[Boost-users] [python] python 3 with boost 1.44, without using bjam

Subject: [Boost-users] [python] python 3 with boost 1.44, without using bjam
From: Geoff Hilton (geoff.hilton_at_[hidden])
Date: 2010-09-08 15:02:21

I'm working on a DLL that I would like to expose to Python as a module, 
but as I came into Python only when Python 3 was available, that's what 
I know and therefore would like to use. A while ago I took a stab at 
learning bjam, but for now I've reverted to regular msvc projects, I was 
able to compile boost.python initially with bjam when I updated to Boost 
1.44, the result generated the following files of relevance:
libboost_python3-vc90-mt-1_44.lib
libboost_python3-vc90-mt.lib
libboost_python3-vc90-mt-sgd-1_44.lib
libboost_python3-vc90-mt-sgd.lib

which is great.. but when I try to compile my project it looks for 
libboost_python-vc90-mt-1_44.lib or libboost_python-vc90-mt-gd-1_44.lib 
as appropriate. How can I make msvc compile it successfully? I know bjam 
is a compiler driver, so I imagine there's a way...

(FYI, here are the compilation commands I use from a batch file when 
compiling a new boost release. I used to use the recommended commands 
but they stopped working when boost changed the naming conventions to 
use version-independent naming, probably because I hadn't modified 
project settings in some way, but a lot of projects would get effected, 
so after some fiddling this is what I came up with).

start bjam --toolset=msvc variant=debug link=static threading=multi 
runtime-link=static stage
start bjam --toolset=msvc variant=release link=static threading=multi 
runtime-link=shared stage

Many thanks,
Geoff

Unrelatedly, a comment I think might be interesting (if only 
speculative): from what I recall, I think boost was partially influenced 
to switch to version-independent naming because (among other reasons) 
Microsoft was using the version-independence way of thinking via the 
.Net model with the GAC, but I found an article at one point (which I 
can no longer find) saying that they realized after much experience with 
.Net that it's actually still quite possible to get version/DLL 
conflicts as a result of the version-independence naming (I believe it 
had to do with GUID generation or some such thing, but don't quote me on 
that), and quite a lot harder to debug. As a result they would be 
rethinking .Net and/or changing to a  model where version-dependence 
plays a more prominent role at some point in the future. I wish I could 
point out the article, but at any rate I know I remember thinking it was 
funny (if possibly unfortunate) that boost was switching to this new 
naming convention, a move partially influenced by Microsoft's current 
methodology in some capacity, after Microsoft had discovered this issue 
and would eventually be (as I understand it) reverting to what 
essentially equates to the traditional pre-.Net DLL where versioning can 
be a more important issue.