[C++-sig] pyste cache

[Scott McKay]

After looking into this a little more I'm not sure what the best
approach is. Gnu make can be made to work by making the .o file
dependent on the .pyste, .hh and .cpp files (previously I had the .cpp
dependent on the .hh and .pyste, and the .o dependent on just the
.cpp). I don't know whether it's preferable to require that in the
makefile world, or whether it's better to always write a .cpp file
even if the cache entry was used.

If the current setup is preferred then maybe the documentation could
have a note added to it about settings the .o dependecies correctly.

Thoughts?

S 

On 6/16/05, Scott McKay <skottmckay at gmail.com> wrote:
> I'll look into making it an option. I have a makefile setup which
> detects that the header has changed and calls pyste, but as that
> doesn't output a changed .cpp file it thinks there's nothing more to
> do.
> 
> Maybe something simple like leaving the current test in place, and
> adding an additional check that if the header was modified more
> recently than the cache file simply touch the output .cpp file.
> 
> S
> 
> On 6/16/05, Nicodemus <nicodemus at esss.com.br> wrote:
> > Scott McKay wrote:
> >
> > >I've noticed that the pyste cache doesn't detect changes like a
> > >declared method in a header having a default implementation added
> > >there, resulting in the changes being ignored.
> > >
> > >
> >
> > No it doesn't. The cache wasn't meant to be bullet-proof; it was
> > implemented only as a way to speed up the process of generating
> > wrappers. The cache is really just the pickled representation of the xml
> > given by gccxml. Reading this pickled file is much faster than calling
> > gccxml and parsing its output, which can help you if you're doing a lot
> > of changes and tests in the pyste files but the source code isn't changing.
> >
> > >Would it be useful to update it to maybe checksum the file as well (or
> > >perhaps just use a checksum for caching purposes rather than the
> > >gccxml output)?
> > >
> > >
> >
> > It could, but I would rather not; I think this is a job for a complete
> > dependency and build system, like SCons' rules. But if someone provides
> > a clean patch and tests, I would happily integrate it. :)
> >
> > Best Regards,
> > Nicodemus.
> >
>