Roman Yakovenko writes:
> On Tue, Dec 15, 2009 at 12:35 AM, Nikolaus Rath wrote:
>> Roman Yakovenko writes:
Certainly all the exported symbols should already be available from
parsing the header file... Is it possible to omit the symbols file
and generate code based only on the he
On Tue, Dec 15, 2009 at 6:33 PM, Nikolaus Rath wrote:
> I'm still curious though: how do you usually handle dependencies on
> system headers?
I don't. I prefer interface, that doesn't expose system ( low-level )
functionality
> If you use the dependency tracing code, it won't be able
> to tell w
On Tue, Dec 15, 2009 at 6:12 PM, Nikolaus Rath wrote:
>> Can you create a small example, which reproduce the problem and send it to
>> me?
>
> The attached file should reproduce the problem, but it needs the fuse
> headers to be installed (Debian/Ubuntu: libfuse-dev). Let me know if
> you don't h
Roman Yakovenko writes:
> On Tue, Dec 15, 2009 at 12:05 AM, Nikolaus Rath wrote:
>> But what I don't understand his this: If exporting only one symbol "a"
>> produces python code that cannot be imported (because it depends on the
>> definition of another symbol 'b' that was not explicitly request
I have seen this page before but I have also never tried as I was looking
for a fast solution.
I was thinking to use boost::shared_ptr because I want to do something like:
// Python code (mystring is boost::shared_ptr)
if object.mystring:
print 'my string: ', object.mystring
Knowing that:
On Tue, Dec 15, 2009 at 9:36 AM, Romain CHANU wrote:
> Hi,
>
> I want to export an attribute which is a boost::shared_ptr and
> I got the following error:
> " TypeError: No Python class registered for C++ class class
> boost::shared_ptr std::char_traits,class std::allocator > > "
> I found an old
