0

I am trying to compile a project using boost.python as documented on this page. My platform is MacOS X, i386 architecture. I am using the current version of boost, v1.55. The example provided in ${BOOST}/libs/python/example/tutorial/ compiles and works properly. However, when setting up my own project in a different directory outside of the boost root directory, I run into the following problem: when I type ${BOOST}/bjam toolset=darwin architecture=x86 address-model=32 I get the following error message:

Unable to load Boost.Build: could not find "boost-build.jam"
---------------------------------------------------------------
Attempted search from ${CURRENT_PATH} up to the root at ${SOME_OTHER_PATH} and in these directories from BOOST_BUILD_PATH and BOOST_ROOT: /usr/share/boost-build.
Please consult the documentation at 'http://www.boost.org'.
make: *** [all] Error 1

The documentation of the bjam tool is not referenced, bjam --help only returns an error message and Googling only finds this page (which doesn't talk about the problem at all) and this page (which seems to be outdated as indicated by the link at the top of the page).

Question: How do I specify the path of the boost-build.jam file? Or, alternatively, is there any other way to use boost.python with standard tools?

Update 3: The option -d4 lets bjam print verbose debugging output. If the name of the compiler is known, the output can be grepped for the compiler invocation. This can then be used to construct a "regular" Makefile. See e.g. this post for an example of how to do so (albeit it assumes that the compile and linker commands are known).

user8472
  • 3,268
  • 3
  • 35
  • 62
  • Most boost libraries are header-only (i.e. you only have to provide the include path to use them), but boost.python is not one of them. It has two parts: the headers and the .so. `bjam`'s only task is to build the .so files, after that you don't need it anymore. Just link to the .so like you would to any other library. – Adam Dec 17 '13 at 08:44
  • @Adam: I had a situation where "just linking to the .so" did not work. The library was not usable in Python unless I used the correct options when linking the file. These turned out to be compiler and platform-specific and they are not identical to the naive expectations. The boost.python tutorial page explicitly recommends to use `bjam` to also build my own artifacts, presumably for the very reasons I have encountered. – user8472 Dec 18 '13 at 05:16
  • Are you married to boost.python for any particular reason? I like some of the design of boost.python, but the build requirements is exactly why I chose SWIG instead. In my opinion if you want to distribute code to others then these build requirements make boost.python a non-starter. Python can be very picky about build flags and some extensions simply won't link. SWIG emits a .cpp file that is compiled along with the rest of your extension. You can, for example, use distutils which will give you all the flags for the particular Python installation you're building for. – Adam Dec 18 '13 at 07:43

0 Answers0