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

[Nicodemus]

Prabhu Ramachandran wrote:

>Hi,
>
>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:
>>>>>>            
>>>>>>
>
>[snip]
>
>    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
>great!
>  
>

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

Regards,
Nicodemus.