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

Nicodemus nicodemus at globalite.com.br
Wed Jun 18 19:34:18 CEST 2003


----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Wednesday, June 18, 2003 1:29 AM
Subject: Re: [C++-sig] Re: Pyste bug - static member functions...


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

Yes, you are right Ralf, thanks for the remainder! I have not used bare
SCons (we use a wrapper around it at work) in some time, so this detail
escaped my mind.






More information about the Cplusplus-sig mailing list