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

[Prabhu Ramachandran]

Hi,

Glad to note that the other Pure/Derived issue was a Pyste bug with
AllFromHeader.  I was quite upset.  SF's CVS being on backup is indeed
a pain!

>>>>> "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 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?

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?  I'd
really appreciate if we could find a decent solution for this.

    >> 1. Can we specify exclude/rename function names in greater
    >>    detail.
    >> Currently its impossible to selectively exclude one particular
    >> overloaded function.

    N> I think that will be solved when meta programming is avaiable
    N> in the Pyste files. I don't know how to stretch the current
    N> syntax to support this, but suggestions are welcome.

OK, there is no hurry for this.  The above is far more important.

    >> 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.

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

Thanks!

regards,
prabhu