[C++-sig] Boost V1 build on Solaris
dave at boost-consulting.com
Wed Nov 6 21:01:16 CET 2002
"Paul F. Kunz" <Paul_Kunz at SLAC.Stanford.EDU> writes:
> One final question, which is not specific to boost::python but
> general question on building Python modules. What my Solaris
> administrators have done is to configure Python with
> > ./configure
> They also did a build fron Linux with the appropriate `exec-prefix'.
> What apparently this has done is to put all but one of the Python
> include files in the directory `common/2.0/include'. But Python.h
> includes `config.h' or `pyconfig.h' (depending on the version) which
> gets installed in `sun4x_55/2.0/include'. This is appropriate since
> this file is machine/OS dependent.
> Now the problem is that boost::python, and other packages, gives you
> one variable, like PYTHON_INCLUDES, for its build. When it is set to find
> `Python.h' it will not find `pyconfig.h'.
> What is the best way to handle this situation? Is it a bug in
> Python's configure script? Bug in boost::python and others? Or am
> I missing something obvious?
Sorry it took so long to come up with an answer, Paul. It was staring
me right in the face the whole time, though:
You just need to make sure your PYTHON_INCLUDES variable has two
elements. Depending on how your shell treats quotes, that could take
several forms. The shells I have available, e.g. bash, will let you
embed a space in a command-line argument as follows:
bjam -sPYTHON_INCLUDES="/afs/.slac.stanford.edu/package/python/common/2.0/include /afs/.slac.stanford.edu/package/python/sun4x_55/2.0/include" ...
And bjam splits up variable values on whitespace boundaries.
Some shells let you set up variables with embedded spaces in the
environment; you might try that if your shell doesn't cooperate when
you try to use quotes in the command-line.
dave at boost-consulting.com * http://www.boost-consulting.com
More information about the Cplusplus-sig