Hi Prabhu, Prabhu Ramachandran wrote:
"N" == nicodemus <nicodemus@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:
pyste.py --out build --multiple -c file1.pyste
N> I don't understand exactly what you are saying. Are you N> suggesting that instead of generating:
N> #include <...> N> BOOST_PYTHON_MODULE(module) { N> class_<A>(...); N> }
N> You want to be able to generate just this: N> class_<A>(...); N> ?
N> How does that help you handle dependencies?
No, what I mean is 'pyste.py --multiple -c file.pyste' should generate this (edited for brevity):
// ------------ _file.cpp ---------- // Includes ===== #include <boost/python.hpp> // Using ======= using namespace boost::python; // Declarations ==== namespace { struct test_A_Wrapper: test::A { [...] }; [ other wrappers etc. ] // Module =========== void _Export_file_pyste() { class_<...> } // ------------ _file.cpp ----------
And without -c this command: pyste.py --module=test --multiple file1.pyste file2.pyste should *only* generate:
// ---------- test.cpp ---------- // Include ============== #include <boost/python.hpp> // Exports =============== void _Export_file_pyste();
// Module ================ BOOST_PYTHON_MODULE(test) { _Export_file_pyste(); } // ---------- test.cpp ----------
I hope this is clear. I think you will see what I am getting at here. This way if file.pyste changes then only _file.cpp changes. None of the other wrapper code sources will change and pyste will run faster since all you need to process is one of the pyste files. Its much easier for users to use and incrementally wrap their libraries and very convenient for development.
I see. Unfortunately this breaks backward compability. 8/ But notice that Pyste only overwrites files if they changed, otherwise it leaves them intact, so as to not disturb build systems out there that depend on time-stamps. I think a good option would be something like --xml-cache=<dir>, where Pyste would get the generated gccxml files, or write them there in case they are not found. The bottleneck with Pyste is always GCCXML, since it has to basically compile the source files. What do you think? Regards, Nicodemus.