[C++-sig] [Py++] Missing struct
Nikolaus Rath
Nikolaus at rath.org
Mon Dec 14 23:05:08 CET 2009
Roman Yakovenko <roman.yakovenko at gmail.com> writes:
> On Mon, Dec 14, 2009 at 7:22 PM, Nikolaus Rath <Nikolaus at rath.org> wrote:
>> No, but that's not what I'm saying. The only dependency here is printf,
>> so Py++ should export do_smth, because it is from the main file, and
>> printf from stdio.h, because do_smth depends on it.
>
> Unfortunately, GCCXML doesn't provide information about function
> implementation and arbitrary C/C++ expression. So Py++ can't see this
> dependency.
Yes, I read the example wrong. See other mail.
>>> Py++ assumes, that files, that belongs to the same directory as the
>>> file you pass, contain "interface", why all others contain
>>> implementation.
>>
>> In my opinion that is not a particularly good assumption. Why not work
>> without it and instead export all the dependencies of the file I'm
>> passing?
>
> Because what you think is good for you is actually bad for me( and
> other users who already use Py++ ).
>
> The assumption has a simple background( at least in my case ): in most
> cases the project dependencies are bigger( more code ) than the
> project itself. So it should be much easier to define what to export,
> then the opposite. You can argue with this, but this is the current
> default behavior and it is not going to change.
No, I think either I don't understand what you are saying or the other
way around. And I'm not arguing about the current implementation being
good or bad (or at least I'm trying not to), but I'm trying to
understand where we don't understand each other :-).
I totally agree with you that it is better to define what to export,
rather than what not to export (actually I'm already calling
global_ns.exclude() first thing in my code).
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 requested),
what is the point of generating the code in the first place? Under which
circumstances do you want to generate code that cannot be imported?
> I understand that your use case is different than my - fine. I believe
> Py++ has all functionality you need, to define what declarations
> should be exported. Consider to use "reverse"logic:
>
> mb = ctypes_module_builder_t( ... )
> mb.global_ns.exclude()
> #and now define what you want to include
>
> May be you should take a look on
> "module_builder/ctypes_decl_dependencies.py" module. It contains
> "find_out_dependencies" functionality. As input it takes a set of
> declarations you want to expose, the output is a set of all classes,
> that need to be exposed.
Actually I already did, but I failed to understand the interface once
again. What exactly is a "set of declarations"? A list of the symbol
names? A list of element as they are returned by e.g.
global_ns.class_('mysymbol')?
Can you tell me how to instruct Py++ to include the struct
'fuse_lowlevel_ops' and everything it that it depends on?
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
More information about the Cplusplus-sig
mailing list