<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 6, 2015 at 2:48 PM, Ben Boeckel <span dir="ltr"><<a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Oct 05, 2015 at 22:46:00 -0600, David Gobbi wrote:<br>
> Currently it isn't feasible for copies of VTK that were built<br>
> against different versions of Python to be installed under<br>
> the same install prefix, because libs like vtkFiltersPython<br>
> would conflict between different Python versions.<br>
><br>
> I propose renaming such libs to e.g. vtkFiltersPythonPy27<br>
> to indicate what version of the Python libs they link to.<br>
> Something similar was already done for the wrapper libs, e.g.<br>
> vtkCommonCorePython27D is CommonCore's wrapper lib.<br>
><br>
> The renaming can be done automatically for any module lib<br>
> that depends on Python, as shown in this merge request:<br>
> <a href="https://gitlab.kitware.com/vtk/vtk/merge_requests/729" rel="noreferrer" target="_blank">https://gitlab.kitware.com/vtk/vtk/merge_requests/729</a><br>
><br>
> Thoughts?<br>
<br>
</span>So…what about modules which *link* to vtkFiltersPython or<br>
vtkPythonInterpreter? Which one do you get? It should be the Python that<br>
is *currently* found in the finding project, but who knows?<br></blockquote><div><br></div><div>Only the filename is changed, not the target name.  CMake</div><div>uses target names to deal with dependencies.</div><div><br></div><div>The only real problem is when non-CMake projects try to find</div><div>these libraries.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This will need module logic awareness to duplicate any modules (and<br>
tests) which link to a versioned library to build for all versions. The<br>
file dropped in the Modules/ directory should also have this suffix so<br>
that vtkFiltersPython27 can coexist with vtkFiltersPython34.<br></blockquote><div><br></div><div>My motivation is to make it possible for the distro folks (e.g.</div><div>debian, arch linux) to build vtk packages... and I agree that</div><div>module awareness of duplicate libraries would be a very nice</div><div>thing (if someone has the time).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't think building a single VTK with Python2 and Python3 from one<br>
build tree is feasible (nevermind multiple versions of either Python2 or<br>
Python3 in the same build).</blockquote><div><br></div><div>What of the distro folks then?  I think we should at least try to meet</div><div>them halfway.</div><div><br></div><div> - David</div><div> </div></div></div></div>