[C++-sig] Pyste: serious bug with --multiple.

Nicodemus nicodemus at globalite.com.br
Mon Jul 7 22:11:54 CEST 2003


Hi Prabhu,

Prabhu Ramachandran wrote:

>>>>>>"N" == nicodemus  <nicodemus at globalite.com.br> writes:
>>>>>>            
>>>>>>
>
>    N> Yes, the idea was that Pyste would generate a xml file for each
>    N> header parsed. Keeping them updated would be the build's system
>    N> job: when a header is modified, it should delete the
>    N> corresponding xml file, so that Pyste would rebuild it.
>
>Oh! OK but its more complicated than my solution.
>

Yes. 8)

>    N> But I don't see a need for the _interface_name_module_init()
>    N> function, since BOOST_PYTHON_MODULE can call them, and the fact
>    N> that Base classes must be exported first, would make things
>    N> complicated.
>
>The reason for the _interface_name_module_init is that I'd like one
>function that has a known name and that is independant of what was
>generated.  This way I can generate the _main.cpp without any need to
>use GCCXML.
>

Hmm, I see. But unfortunately this will cause problems, such as:

test.h ----
struct A {};
struct B: A {};

x.pyste ----
Class('A', 'test.h')

y.pyste ----
Class('D', 'test.h')



You would have two functions, init_x and init_y, but you have to call 
first init_x, otherwise you will get a runtime error. That's why I think 
more control of which class is instanciated first is needed. Of course, 
we can demand that our users put all files in a hierarchy in the same 
Pyste file, but that breaks the purpose of the --multiple option (to 
reduce compile time), since it is common that type hierarchies have a 
base class that all other classes derive from; besides this gives the 
users one more thing to worry about.

Regards,
Nicodemus.





More information about the Cplusplus-sig mailing list