hello.pyd - where did it go?
Hi, I just installed boost 1.32 on linux - I want to use Boost.Python. The installation seemed to go ok. After that I tried the hello world example http://www.boost.org/libs/python/doc/tutorial/doc/html/python/hello.html % cd boost_1_32_0/libs/python/example/tutorial % bjam -sTOOLS=gcc -a This seems to work also - a hello.so is created and copied to boost_1_32_0/bin/boost/libs/python/example/tutorial/hello.so but where did hello.pyd go? The above hello.html page says it's supposed to be "somewhere in libs\python\example\tutorial\bin" But it's not there. I have not used bjam prior to boost so I'm a little confused - is it possible to see what the commandline eqivalents of what bjam is actually doing? Is boost usable without bjam? Cheers Jesper
Jesper Olsen <jesper.olsen@gmail.com> writes:
Hi,
I just installed boost 1.32 on linux - I want to use Boost.Python.
The installation seemed to go ok.
After that I tried the hello world example
http://www.boost.org/libs/python/doc/tutorial/doc/html/python/hello.html
% cd boost_1_32_0/libs/python/example/tutorial % bjam -sTOOLS=gcc -a
This seems to work also - a hello.so is created and copied to
boost_1_32_0/bin/boost/libs/python/example/tutorial/hello.so
but where did hello.pyd go? The above hello.html page says it's supposed to be "somewhere in libs\python\example\tutorial\bin"
But it's not there.
I have not used bjam prior to boost so I'm a little confused - is it possible to see what the commandline eqivalents of what bjam is actually doing?
Add "-d+2" to your bjam command line, just after "bjam" If you've already built something, use "-a" to cause bjam to treat everything as being out-of-date and "-n" to cause bjam not to build anything, but display the commands that would be executed. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Jesper Olsen <jesper.olsen@gmail.com> writes:
Hi,
I just installed boost 1.32 on linux - I want to use Boost.Python.
The installation seemed to go ok.
After that I tried the hello world example
http://www.boost.org/libs/python/doc/tutorial/doc/html/python/hello.html
% cd boost_1_32_0/libs/python/example/tutorial % bjam -sTOOLS=gcc -a
This seems to work also - a hello.so is created and copied to
boost_1_32_0/bin/boost/libs/python/example/tutorial/hello.so
but where did hello.pyd go? The above hello.html page says it's supposed to be "somewhere in libs\python\example\tutorial\bin"
But it's not there.
I have not used bjam prior to boost so I'm a little confused - is it possible to see what the commandline eqivalents of what bjam is actually doing?
Add "-d+2" to your bjam command line, just after "bjam"
If you've already built something, use "-a" to cause bjam to treat everything as being out-of-date and "-n" to cause bjam not to build anything, but display the commands that would be executed.
Time to update the tutorial? Is it not a good idea to put bjam generated directory paths there since these are subject to change? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On Thu, 17 Mar 2005 23:49:32 +0800, Joel de Guzman <djowel@gmail.com> wrote:
David Abrahams wrote:
Jesper Olsen <jesper.olsen@gmail.com> writes:
I have not used bjam prior to boost so I'm a little confused - is it possible to see what the commandline eqivalents of what bjam is actually doing?
Add "-d+2" to your bjam command line, just after "bjam"
If you've already built something, use "-a" to cause bjam to treat everything as being out-of-date and "-n" to cause bjam not to build anything, but display the commands that would be executed.
Time to update the tutorial? Is it not a good idea to put bjam generated directory paths there since these are subject to change?
Thanks. I was able to run the tutorial - what was necessary after running bjam in the example/tutorial directory, was to add .../../../../bin/boost/libs/python/example/tutorial/hello.so/gcc/debug/shared-linkable-true/ to sys.path (python) and setting the shell variable LD_LIBRARY_PATH LD_LIBRARY_PATH=/usr/local/lib/python2.4/config:../../../../bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true:$LD_LIBRARY_PATH Looking at the bjam -d 2 output it seems it tries to set LD_LIBRARY_PATH to this value - but it is not defined when it finishes... Anyway - I'm glad it's working now. I think the python bridge is very cool - much easier than writing the usual c interface files. However - installation and distribution of code is less streamlined than using python distutils - but I guess it was not the intention to replace that anyway. Cheers Jesper
Jesper Olsen <jesper.olsen@gmail.com> writes:
On Thu, 17 Mar 2005 23:49:32 +0800, Joel de Guzman <djowel@gmail.com> wrote:
David Abrahams wrote:
Jesper Olsen <jesper.olsen@gmail.com> writes:
I have not used bjam prior to boost so I'm a little confused - is it possible to see what the commandline eqivalents of what bjam is actually doing?
Add "-d+2" to your bjam command line, just after "bjam"
If you've already built something, use "-a" to cause bjam to treat everything as being out-of-date and "-n" to cause bjam not to build anything, but display the commands that would be executed.
Time to update the tutorial? Is it not a good idea to put bjam generated directory paths there since these are subject to change?
Thanks.
I was able to run the tutorial - what was necessary after running bjam in the example/tutorial directory, was to add .../../../../bin/boost/libs/python/example/tutorial/hello.so/gcc/debug/shared-linkable-true/ to sys.path (python) and setting the shell variable LD_LIBRARY_PATH LD_LIBRARY_PATH=/usr/local/lib/python2.4/config:../../../../bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true:$LD_LIBRARY_PATH
That should not be neccessary. There are testing rules to run python tests from within the bjam invocation; they set up the paths as neccessary and then run python.
Looking at the bjam -d 2 output it seems it tries to set LD_LIBRARY_PATH to this value
Yes.
- but it is not defined when it finishes...
I don't know what you mean. If you were expecting that LD_LIBRARY_PATH setting to remain after the bjam invocation is complete, well, Boost.Build intentionally does not alter anything in the invocation environment.
Anyway - I'm glad it's working now. I think the python bridge is very cool - much easier than writing the usual c interface files. However - installation and distribution of code is less streamlined than using python distutils - but I guess it was not the intention to replace that anyway.
Well, it is our intention to fully replace distutils for the purposes of C++, very soon. And distutils was very bad at dealing with C++ last time I looked. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Sun, 20 Mar 2005 15:42:01 -0500, David Abrahams <dave@boost-consulting.com> wrote:
Jesper Olsen <jesper.olsen@gmail.com> writes:
Anyway - I'm glad it's working now. I think the python bridge is very cool - much easier than writing the usual c interface files. However - installation and distribution of code is less streamlined than using python distutils - but I guess it was not the intention to replace that anyway.
Well, it is our intention to fully replace distutils for the purposes of C++, very soon. And distutils was very bad at dealing with C++ last time I looked.
I'm glad to hear that. Nevertheless - boost is very big - much bigger than c-python. I put it on a webserver, where it made a serious dent in the harddisk space. Distutils is not great as a build environment - but you can tell it to eg. use g++ as the linker - so that your extension can be in C++ as long as the python interface is C... But one thing I find frustrating is that it shields you from platform specific details - making it very hard to e.g. pass "unusual" options to the compiler etc. The good thing about disutils though is that it is very easy to give your source code to someone else - and they will be able to install it and use with very little fuss. Cheers Jesper
Jesper Olsen <jesper.olsen@gmail.com> writes:
On Sun, 20 Mar 2005 15:42:01 -0500, David Abrahams <dave@boost-consulting.com> wrote:
Jesper Olsen <jesper.olsen@gmail.com> writes:
Well, it is our intention to fully replace distutils for the purposes of C++, very soon. And distutils was very bad at dealing with C++ last time I looked.
I'm glad to hear that. Nevertheless - boost is very big - much bigger than c-python. I put it on a webserver, where it made a serious dent in the harddisk space.
I'm not sure what you're getting at, but Boost.Build is an independent component that can be used without the rest of Boost.
Distutils is not great as a build environment - but you can tell it to eg. use g++ as the linker - so that your extension can be in C++ as long as the python interface is C...
Assuming you are using g++. But how is it at doing C++ on other compilers without a lot of user intervention? That was one of the big problems last I looked.
But one thing I find frustrating is that it shields you from platform specific details - making it very hard to e.g. pass "unusual" options to the compiler etc.
Boost.Build also shields you, but there are plenty of "backdoor" escapes to help you around such limitations when neccessary.
The good thing about disutils though is that it is very easy to give your source code to someone else - and they will be able to install it and use with very little fuss.
We're hoping that will be the case with Boost.Build very soon. Even more so once the Python rewrite is done ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Jesper Olsen <jesper.olsen@gmail.com> writes:
The good thing about disutils though is that it is very easy to give your source code to someone else - and they will be able to install it and use with very little fuss.
We're hoping that will be the case with Boost.Build very soon. Even more so once the Python rewrite is done ;-)
I might be wrong, but I believe you said once that one of the design decisions about Boost.Build was that it shouldn't depend on other software; that's the reason (I believe) SCons couldn't be considered as a replacement, since it depends on Python. Has this decision changed? Very nice to hear about the Python port, btw. :) Regards, Nicodemus.
Nicodemus <nicodemus@esss.com.br> writes:
David Abrahams wrote:
Jesper Olsen <jesper.olsen@gmail.com> writes:
The good thing about disutils though is that it is very easy to give your source code to someone else - and they will be able to install it and use with very little fuss.
We're hoping that will be the case with Boost.Build very soon. Even more so once the Python rewrite is done ;-)
I might be wrong, but I believe you said once that one of the design decisions about Boost.Build was that it shouldn't depend on other software; that's the reason (I believe) SCons couldn't be considered as a replacement, since it depends on Python. Has this decision changed?
It seems so.
Very nice to hear about the Python port, btw. :)
It's already been started. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
David Abrahams -
Jesper Olsen -
Joel de Guzman -
Nicodemus