On Wed, Sep 25, 2013 at 10:06 PM, Kassiopi Kassiopi2 <kassio...@gmail.com>wrote:
> 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?
>
Just link the command manager in dynamic everywhere. (you your singleton
will works that way)
>
>
> On Tue, Sep 24, 2013 at 11:06 AM, Raghvendra Jain <
> raghavendra.j...@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.corbe...@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@copanitalia.**com<giuseppe.corbe...@copanitalia.com>
>>>
>>> ______________________________**_________________
>>> Cplusplus-sig mailing list
>>> Cplusplus-sig@python.org
>>> https://mail.python.org/**mailman/listinfo/cplusplus-sig<https://mail.python.org/mailman/listinfo/cplusplus-sig>
>>>
>>
>>
>> _______________________________________________
>> Cplusplus-sig mailing list
>> Cplusplus-sig@python.org
>> https://mail.python.org/mailman/listinfo/cplusplus-sig
>>
>
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig@python.org
> https://mail.python.org/mailman/listinfo/cplusplus-sig
>
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig
