Roman Yakovenko <roman.yakove...@gmail.com> writes: > On Tue, Dec 15, 2009 at 12:05 AM, Nikolaus Rath <nikol...@rath.org> 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 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? > > Consider use case, where your code is split between different modules: > > module Base: > struct B; > > module Derived1: > d( B* ) > > module Derived2: > d2( B* ) > > In this case, when you exposed Derived* you don't want to expose struct B.
With modules you mean files in this context, right? I guess I finally understand. So you would have 'struct B' in one file and something that uses struct B in a different file. Then both files are translated to ctypes separately, but as long as they are both imported, all the required symbols are defined. Sorry that it took me so long ;-). I'm still curious though: how do you usually handle dependencies on system headers? If you use the dependency tracing code, it won't be able to tell which dependencies are from system files (and should be included) and which dependencies are from project headers (and are going to be exported separately). Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
