David Abrahams <dave@boost-consulting.com> writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> 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 process_jam_log.
Sorry, I don't remember :(
I'll try to do an analysis later today. Thanks for looking at this.
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 succeeded.
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