[C++-sig] Re: Pyste bug - static member functions...

[Ralf W. Grosse-Kunstleve]

--- Nicodemus <nicodemus at globalite.com.br> wrote:
>  From my experience with SCons, it would actually simpler the other way. 
> You make your build system generate the gccxml files and the pyste 
> files. Whenever a header changes, the related gccxml file will be 
> rebuilt, and consequently the pyste file will be rebuilt also. With 
> --cache, you would have to make your build system generate the command 
> line with the dictionary-like syntax, which I believe would be more 
> complicated than a static command line "python pyste.py --module=foo 
> --xml-dir=xml-cache bar.pyste bah.pyste"?

Sorry if this is a stupid suggestion (I have not used pyste ever although I
find it very exciting): it seems to me what you really need a .pyste scanner,
analog to the dependency scanner for .cpp files. The scanner would recursively
search all files that a .pyste file depends on. Then you define an action that
determines what to do if any of the dependencies has changed. The user will
never see these details, but simply specify:

BoostPythonExtension(target="foo", sources=["bar.pyste", "bah.pyste"])

I am guessing one could mix .pyste and manually coded .cpp files without having
to do anything special:

BoostPythonExtension(target="foo", sources=["bar.pyste", "bah.pyste",
"custom.cpp"])

The intermediate xml files would automatically stay around just like .o files
until the user runs scons --clean. Optionally combine this with Scons'
Repository() feature to keep the source code trees free of derived files at all
times.

Ralf


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com