Hi Karl,

Karl Rupp <r...@iue.tuwien.ac.at> writes:
>  From a maintenance point of view we really need to make sure that we 
> can update PyViennaCL and/or ViennaCL without creating lots of 
> headaches. This will not only help us, but also our prospective users 
> and packagers. From your description it seems that the best way to 
> achieve just this is to split the trees up. :-)

Right, then, I'll do that.

In other news, I've now got PyViennaCL configured so that it can
autodetect the right Python and Boost Python version to use. Ubuntu and
Debian are slightly non-standard in how they name their libboost_python*
shared object files, so my script stores quirks for various
systems. Hopefully that'll be easy to maintain (so far, there are only
two quirks..), and make life easy for users. All that they need to do,
if they are using a non-standard path to the interpreter is

cd build
cmake -D PYTHON_INTERPRETER=python3 ..

etc (replacing 'python3' with the path to their interpreter as
needed). Which is good -- no more editing of CMakeLists.txt! I might
change PYTHON_INTERPRETER to PYTHON_EXECUTABLE, since that might be more
standard, but I'm not sure how well that will play out right now. I will

> Also, feel free to push changes to the ViennaCL core as needed :-)

That's a brave licence to give me! Luckily, I've not needed to make any
changes in a while. But hopefully, once things have settled a bit and I
get into a release cadence, I can start doing some dev work on the core,
since that's where most of the interesting stuff happens.



October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
ViennaCL-devel mailing list

Reply via email to