[C++-sig] Alternate locations for BOOST_PYTHON_MODULE

[Holger Brandsmeier]

Trevor,

ok, so I misunderstood your question. If what you want to do is this:

---- myclass.h
class MyClass {
[...]
};

---- pythonFile.cpp
#include "myclass.h"
[...]

BOOST_PYTHON_MODULE(...) {
[...]
}

That is certainly possible, I think almost everyone (including me)
does it like this.

> Also, I am not tied to usnig bjam, that is just what the boost.python tutorial recommended. How are you compiling your python extension modules? Can you point me to some information about it?

I recommend you to use bjam, I simply can not help you about it.

-Holger


On Wed, Jun 12, 2013 at 12:10 PM, Trevor Haba <Trevor.Haba at logmein.com> wrote:
> Holger,
>
> Thanks for the reply. I'm a little bit confused about the .inl file. Sorry if these are obvious questions, I'm still somewhat new at this.
>
> So this "pfemPy.inl" is what actually contains the python bindings? So the commands like class_<foo>("foo").def(...) are in the .inl file? Are these wrapped in their own BOOST_PYTHON_MODULE(...) {} block, or are they in some other format? Then PfemInst::call(), what does that do? I'm a little bit confused, if you are still writing the wrapper calls, why not just put them in the BOOST_PYTHON_MODULE you have here? Why keep them in a seperate file, #include them and then use the ::call() function?
>
> Also, I am not tied to usnig bjam, that is just what the boost.python tutorial recommended. How are you compiling your python extension modules? Can you point me to some information about it?
>
> Thanks for your help,
> Trevor
>
> -----Original Message-----
> From: Cplusplus-sig [mailto:cplusplus-sig-bounces+trevor.haba=logmein.com at python.org] On Behalf Of Holger Brandsmeier
> Sent: Wednesday, June 12, 2013 11:27 AM
> To: Development of Python/C++ integration
> Subject: Re: [C++-sig] Alternate locations for BOOST_PYTHON_MODULE
>
> Trevor,
>
> that is certainly possible, all my python exports look like this:
>
> #include "pfemPy.inl"
>
> BOOST_PYTHON_MODULE(pfemPy)
> {
>   PfemInst::call();
> } // boost module
>
> Then e.g. in "pfemPy.inl" I wrap and export the C++ classes. The file "pfemPy.inl" in turn includes the header of the required source which are "untoched".
>
> I can not help you about the Jamroot, as I am not using bjam.
>
> -Holger
>
> On Wed, Jun 12, 2013 at 11:05 AM, Trevor Haba <Trevor.Haba at logmein.com> wrote:
>> Hello,
>>
>>
>>
>> I am attempting to make a large pre-existing code base accessible to
>> python, so that I can run quick scripts to automate the behavior of
>> certain classes for testing purposes. We are using C++ and python 3.3
>> with the boost.python library. I have a script to automatically
>> generate the BOOST_PYTHON_MODULE( … ) wrapper definitions for the C++
>> source code. But, because this is a pre-existing code base with other
>> people already working on it, I would prefer to not have to modify the
>> source code files of all of the classes by inserting the python
>> wrappers at the bottom. All the examples I’ve seen show the
>> BOOST_PYTHON_MODULE at the bottom of the C++ source file. Is it
>> possible to put the BOOST_PYTHON_MODULE in a separate file, and
>> #include the class it is wrapping? If so, how would I do this? And how would I configure the Jamroot file to compile these properly?
>>
>>
>>
>> Also, I’m targeting windows systems and using Visual Studio 2010, if
>> that matters
>>
>>
>>
>> Thanks very much,
>>
>> Trevor
>>
>>
>>
>>
>> _______________________________________________
>> Cplusplus-sig mailing list
>> Cplusplus-sig at python.org
>> http://mail.python.org/mailman/listinfo/cplusplus-sig
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig