[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