[C++-sig] Pyste: feature requests

Prabhu Ramachandran prabhu at aero.iitm.ernet.in
Sat Jul 5 19:01:30 CEST 2003

Hi Nicodemus,

>>>>> "N" == nicodemus  <nicodemus at globalite.com.br> writes:

    >> >> 1. Something like the C compiler's '-c' option.  In this case
    >> >>    Pyste
    >> >> should simply generate the wrapper code and none of the
    >> >> module code i.e. for an invocation like so:

    N> I see. Unfortunately this breaks backward compability. 8/ But
    N> notice that Pyste only overwrites files if they changed,
    N> otherwise it leaves them intact, so as to not disturb build
    N> systems out there that depend on time-stamps.

Yes, I noticed the SmartFile while poking around.  Neat.

If backwards compatibility is the problem you could always define a
new option that does not interfere with the current working.
Something like this:

             for individual files with only the export functions
             and without generating the module code.

             for the main module.cpp file that calls the exports and
             initializes the module.

    N> I think a good option would be something like
    N> --xml-cache=<dir>, where Pyste would get the generated gccxml
    N> files, or write them there in case they are not found. The
    N> bottleneck with Pyste is always GCCXML, since it has to
    N> basically compile the source files. What do you think?

Yes, that also sounds OK to me.  If the wrapper-generation time will
drop and not every single file will be re-parsed/compiled and wrapped
then I'm OK with a --xml-cache option.  

Basically, the trouble is that with many .pyste files its a pain
changing just one Pyste file and waiting for a long while for pyste
(gccxml actually) to finish.

The other desireable feature would be to dump only one file per .pyste
file.  This makes dependencies with something like SCons a non-issue.
If not its hard to figure out which files depend on what.  Again if
backwards compatibility is a problem perhaps another option --one-file
needs to be added.



More information about the Cplusplus-sig mailing list