Hi Toby, > As I've been crafting the cmake files in order to prepare for a > PyViennaCL release, I've realised that the more I do this, the more the > PyViennaCL tree diverges from upstream, and the more merges I'll have to > take care of whenever I pull in upstream changes. So I've been more and > more thinking that the best strategy for PyViennaCL is probably the one > that one of you suggested when I begun (I should have listened!): have > PyViennaCL in a different tree, pulling in ViennaCL as needed. > > I won't bother doing the rearranging right now, before the first > release, but I'll probably do it soon after if you agree it's sensible.
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. :-) Also, feel free to push changes to the ViennaCL core as needed :-) Best regards, Karli ------------------------------------------------------------------------------ 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 > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
