[C++-sig] Re: hello.pyd - where did it go?

[David Abrahams]

Jesper Olsen <jesper.olsen at gmail.com> writes:

> On Thu, 17 Mar 2005 23:49:32 +0800, Joel de Guzman <djowel at gmail.com> wrote:
>> David Abrahams wrote:
>> > Jesper Olsen <jesper.olsen at 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