Hi,
I think this text on this page: https://www.preney.ca/paul/archives/107
relates to the issue I’m having:
It is very important that "libyay" in BOOST_PYTHON_MODULE(libyay) matches the
name of the library you're generating in CMakeLists.txt (without the extension).
NOTE: On Linux / Unix systems you will need to prefix the name with "lib" as
CMake defaults to prepending the file with "lib" as per convention on Linux /
Unix systems.
Essentially, the BOOST_PYTHON_MODULE clause exports the "yay" function as the
Python symbol name "yay". This will allow you to call the "yay" function from
Python later.
> On Sep 8, 2016, at 6:33 PM, Jon Lederman <jonleder...@gmail.com> wrote:
>
> Hi,
>
> Ok. I have removed all the opus library dependencies and stripped away much
> of everything else. It seems to me that the name of the generated .so has to
> match the name of the module. Perhaps I am building incorrectly. I am using
> make.
>
>
>
> -Jon
>
> #ifndef OPUS_ENCODER_STRATEGY_H_
> #define OPUS_ENCODER_STRATEGY_H_
>
> #include "memory"
> #include <boost/python.hpp>
> #include <boost/numpy.hpp>
> #include <exception>
> #include <memory>
> #include <map>
> #include <vector>
> #include <iostream>
>
> namespace bp = boost::python;
> namespace np = boost::numpy;
>
> using namespace std;
>
>
> class OpusEncoderStrategy {
>
> public:
>
> OpusEncoderStrategy(){};
> ~OpusEncoderStrategy(){};
>
> int fs;
> int channels;
> int application;
> int error;
>
>
> };
>
>
> BOOST_PYTHON_MODULE(opus_strategy)
> {
> using namespace boost::python;
>
> class_<OpusEncoderStrategy>("OpusEncoderStrategy", init<const int,
> const int, const int>());
> }
>
>
> #endif
>> On Sep 8, 2016, at 6:00 PM, Stefan Seefeld <ste...@seefeld.name> wrote:
>>
>> Hi Jon,
>>
>> please remove the dependency on the "opus/*" headers, so we can compile
>> the module ourselves and try to reproduce what you are reporting.
>> (That's what I meant with "self-contained test".)
>>
>>
>> Thanks,
>> Stefan
>>
>> On 08.09.2016 17:30, Jon Lederman wrote:
>>> Hi,
>>>
>>> Thanks for responding. Here is my header file. I am compiling this to a
>>> shared object called opus_strategy.so. If I set the argument of
>>> BOOST_PYTHON_MODULE to opus_encoder_strategy, and compile my .so file to
>>> have the name opus_encoder_strategy.so,I can load the boost python module
>>> into my python interpreter and see the OpusEncoderStrategy class as an
>>> attribute.
>>>
>>> However, if I choose other names such as opus_strategy for the argument to
>>> BOOST_PYTHON_MODULE, when I load the boost python object it doesn’t appear
>>> to have any recognized attributes. I don’t understand why the name should
>>> matter. As I had noted in my previous email, I would like to have a shared
>>> object file with the name opus_strategy.so that encompasses a set of
>>> classes. Just can’t figure out how to get it to work. I am on OS X, BTW
>>> if that matters.
>>>
>>> Any help would be greatly appreciated.
>>>
>>> Thanks.
>>>
>>> -Jon
>>> #ifndef OPUS_ENCODER_STRATEGY_H_
>>> #define OPUS_ENCODER_STRATEGY_H_
>>>
>>>
>>>
>>>
>>>
>>> #include "memory"
>>> #include "opus/opus.h"
>>> #include "opus/opus_defines.h"
>>> #include "opus/opus_multistream.h"
>>> #include "opus/opus_types.h"
>>>
>>> #include <boost/python.hpp>
>>> #include <boost/numpy.hpp>
>>> #include <exception>
>>> #include <memory>
>>> #include <map>
>>> #include <vector>
>>> #include <iostream>
>>>
>>> namespace bp = boost::python;
>>> namespace np = boost::numpy;
>>>
>>> using namespace std;
>>>
>>>
>>> class OpusEncoderStrategy {
>>>
>>> public:
>>>
>>> OpusEncoderStrategy(const int sample_rate, const int number_channels,
>>> const int opus_application);
>>> ~OpusEncoderStrategy();
>>>
>>> opus_int32 encode(const float* pcm, const int frame_size, const
>>> unsigned char* data, opus_int32 max_data_bytes);
>>>
>>> bool setComplexity(const int c);
>>> int getComplexity();
>>>
>>>
>>> private:
>>>
>>> bool encoderCtl();
>>> int getPacketDurationBytes();
>>>
>>>
>>>
>>> OpusEncoder* encoder;
>>>
>>> int fs;
>>> int channels;
>>> int application;
>>> int error;
>>>
>>>
>>> };
>>>
>>>
>>> BOOST_PYTHON_MODULE(opus_strategy)
>>> {
>>> using namespace boost::python;
>>>
>>>
>>> class_<OpusEncoderStrategy>("OpusEncoderStrategy", init<const int,
>>> const int, const int>())
>>> .def("setComplexity", &OpusEncoderStrategy::setComplexity)
>>> .def("getComplexity", &OpusEncoderStrategy::getComplexity);
>>> }
>>>
>>>
>>> #endif
>>>> On Sep 8, 2016, at 4:47 PM, Stefan Seefeld <ste...@seefeld.name> wrote:
>>>>
>>>> Hi Jon,
>>>>
>>>> what you are describing makes perfect sense, and should work without
>>>> problem. From your description it isn't clear why this isn't working, so
>>>> I suggest you put together a self-contained test that doesn't work as
>>>> you expect, and send that out so we can have a look. Otherwise we'd have
>>>> to guess.
>>>> The online docs at http://boostorg.github.io/python/doc/html/index.html
>>>> should contain everything you need.
>>>>
>>>> Stefan
>>>>
>>>> --
>>>>
>>>> ...ich hab' noch einen Koffer in Berlin...
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> --
>>
>> ...ich hab' noch einen Koffer in Berlin...
>>
>> _______________________________________________
>> 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
