From: Misha Bergal (mbergal_at_[hidden])
Date: 2004-10-03 19:56:59
David Abrahams <dave_at_[hidden]> writes:
> Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
>>>> For one, args_ext.pyd was built in args_ext.pyd directory and xml
>>>> result file with failure was written in args_ext.pyf/... directory.
> I don't think there's anything in the build process that should make
> an extension of .pyf
>>>> It is not clear to me what happens in Boost.Python build next.
>>>> At this point I would appreciate if somebody clarified to me how
>>>> Boost.Python build works, so I can figure out how to handle it in
>>> Sorry, I don't remember :(
>>> I'll try to do an analysis later today. Thanks for looking at
>> Dave, did you have a chance to look at it?
> I'm not sure if this is the info Misha needs, but: The embedding test
> is essentially just a normal test that builds and runs an application.
> All of the other tests have two parts: building one or more shared
> libraries (the pyd files are just dlls with a different extension),
> and running the Python application to test them. The .run file
> contains the output of invoking Python, and if the result code is
> zero, the .test file gets created to mark the test as having
Thanks for info. I've made a patch to bjam (make1.c) which seems to
help (see results for const_argument at http://tinyurl.com/6uw2m). I
am not an expert on Boost.Build, so I am not sure that what I did was
the best way to deal with the problem. I will post the patch to
boost.build mailing list, to get some expert feedback on this.
-- Misha Bergal MetaCommunications Engineering
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk