[C++-sig] Pyste: added new build options.

Nicodemus nicodemus at globalite.com.br
Mon Jul 7 23:27:14 CEST 2003

Prabhu Ramachandran wrote:

>Glad to note that the other Pure/Derived issue was a Pyste bug with
>AllFromHeader.  I was quite upset.  

I can imagine. 8)

>>>>>>"N" == nicodemus  <nicodemus at globalite.com.br> writes:
>    N> I didn't check it in yet because I think there is one thing
>    N> that is still pending. See my other post, about the order of
>    N> instantiation of classes.
>[From other message]
>    N> Hmm, I see. But unfortunately this will cause problems, such
>    N> as:
>    N> test.h ----
>    N> struct A {};
>    N> struct B: A {};
>    N> x.pyste ----
>    N> Class('A', 'test.h')
>    N> y.pyste ----
>    N> Class('D', 'test.h')
>    N> You would have two functions, init_x and init_y, but you have
>    N> to call first init_x, otherwise you will get a runtime
>    N> error. That's why I think more control of which class is
>    N> instanciated first is needed. Of course, we can demand that our
>    N> users put all files in a hierarchy in the same Pyste file, but
>    N> that breaks the purpose of the --multiple option (to reduce
>    N> compile time), since it is common that type hierarchies have a
>    N> base class that all other classes derive from; besides this
>    N> gives the users one more thing to worry about.
>Arghh!  This is a pain.  Another issue is if two pyste files export
>different functions (free functions) from the same header we will end
>up with a name clash but I'm assuming that users can be asked to
>export all functions from the same file.

I would like to avoid that kind of thing... it is error prone, and only 
generates compile time errors, which are a pain to read.

>I really like the feature of generating individual files and then
>generating a _main.cpp file.  It makes a huge difference to building
>wrappers.  So I'd like to see some sort of solution for this.  Perhaps
>the --multiple option will generate a separate special file that
>contains information on the bases of each class that was exported.
>Something like this:
>_file1 = {'A':('Export_A', [])}
>_file2 = {'B': ('Export_B', ['A'])}
>I'm tired and not quite thinking straight but the idea is that you
>generate information on what depends on what and append that
>information to a file.  I think this should be a reasonable solution,
>even if its a hack -- perhaps there is a better way?  Do only the
>order of wrappers and class declarations matter?

But then to generate the main.cpp you must have already generated all 
the others? I think that makes things more complicated than are worth... 8/
Perhaps the --xml-cache option would be better, if we can't solve this 
problem? Another option would be to make Pyste accept some xml files.

>OTOH, when GCCXML parses the file you already know the base classes of
>a particular class, so can one generate a special name for the Module
>function such that when it is sorted you will get the right order?
>Consider that class B is the base and A is derived from it.
> class B ->  Export_A_B
> class A ->  Export_B_A
>Then looking at the Export functions one could decide which function
>to call first.  What do you think?  Is there a way out of this?  

But how would we know the name of the functions when we will generate 
main.cpp without calling GCCXML (which is the point of having "Export" 
functions in the files)?

>    >> 2. The current --multiple option generates one file per
>    >>    interface
>    >> file.  I guess that is OK but maybe it would be useful to
>    >> optionally specify the output filename in the interface.  I
>    >> think this should be a low priority to do item (if at all it is
>    >> useful).
>    N> I think it would clutter the command line interface a little,
>    N> but if it is useful we could add it.
>No, its not that useful.

Hmm, ok then.

>Right now I think having a working --only-wrap/only-main would be

Ok, let us focus on that. I am working at the virtual operators too.


More information about the Cplusplus-sig mailing list