[C++-sig] Boost python simple interfacing

[Kassiopi Kassiopi2]

Hi,

I apologize for the delayed reply.

I was hoping to avoid linking the commandManager into the .so file. I am
trying to avoid that because then, I will have to do this for any other
module that I create and uses the commandManager. I would prefer to declare
it as extern or something similar if possible. If I link it into to .so,
then I will have to link it to all the modules I intend to create,
separately. Moreover, the commandManager is statically linked into my
executable, so linking it in every single python module, feels like
overkill.
Furthermore, since my call to the commandManager looks like:

GetCommandManager()->submitCommand( new newDocumentCommand(makeActive) );

I will have to also link against the commands that will be sent to the
commandManager as well. And if there are hundreds of commands, it's obvious
that there is a lot of redundant stuff, since all these classes are also
declared, defined and statically linked in the executable of my application.

So it all ends up to the question: Is it absolutely necessary? No other way?


On Tue, Sep 24, 2013 at 11:06 AM, Raghvendra Jain <
raghavendra.jain at gmail.com> wrote:

> Well, I have embedded an interpreter inside  C++ code, if your question is
> related to that, please write back. May be I can help you with that.
> cheers,
> Raghav
>
>
> On Tue, Sep 24, 2013 at 4:33 PM, Giuseppe Corbelli <
> giuseppe.corbelli at copanitalia.com> wrote:
>
>> On 21/09/2013 16:52, Kassiopi Kassiopi2 wrote:
>>
>>> Hi,
>>>
>>> I want to call a c++ function from an embedded python shell, using boost
>>> python. All the examples I've seen online describe how to expose a whole
>>> class
>>> or some functions, but all cases refer to *standalone* parts of code.
>>>
>>> My case is different though. The function I want to expose is not
>>> standalone,
>>> and has a dependency:
>>>
>>> ------- start of documentModule.cpp --------
>>> #include <commandManager.hpp>
>>> #include <boost/python.hpp>
>>>
>>> void newDocument( bool makeActive ) {
>>>       // depends on commandManager here
>>>      GetCommandMananager()->**submitCommand( new newDocumentCmd(
>>> makeActive ) );
>>> }
>>>
>>> BOOST_PYTHON(documentModule) {
>>>      using namespace boost::python;
>>>      def( "newDocument", myCadLib::pythonCommands::**newDocument,
>>> arg("makeActive") );
>>> }
>>> ------- end of documentModule.cpp --------
>>>
>>> In reality the situation is more complicated and there are more
>>> dependencies
>>> than the one mentioned above.
>>> After generating a .so file with distutils, when I start my application
>>> and I
>>> attempt to load the module (.so file) in the embedded python shell I get
>>> an
>>> undefined symbols error complaining about the commandManager class.
>>> Of course this is a reasonable request from python and I understand that.
>>> However, I don't really care to generate a standalone python module per
>>> se. I
>>> just want it to work in my application's embedded python shell.
>>> Additionally,
>>> it wouldn't be meaningful to have the commandManager class exposed as
>>> well,
>>> since this is part of my applications internal structure.
>>>
>>
>> Seems to me you want both extending and embedding. Never embedded an
>> interpreter in a C++ app, so I'm not of much use here.
>> The two jobs should be fairly independent. Producing the .so to extend
>> the interpreter needs to link the commandManager library.
>> Your extension module needs to access the Command Manager, so make sure
>> it has already been initialized before the module is loaded, else the
>> GetCommandManager() may return NULL.
>>
>> --
>>             Giuseppe Corbelli
>> WASP Software Engineer, Copan Italia S.p.A
>> Phone: +390303666318  Fax: +390302659932
>> E-mail: giuseppe.corbelli at copanitalia.**com<giuseppe.corbelli at copanitalia.com>
>>
>> ______________________________**_________________
>> Cplusplus-sig mailing list
>> Cplusplus-sig at python.org
>> https://mail.python.org/**mailman/listinfo/cplusplus-sig<https://mail.python.org/mailman/listinfo/cplusplus-sig>
>>
>
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> https://mail.python.org/mailman/listinfo/cplusplus-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20130925/5dfe8aea/attachment.html>