Hello, The ebuilds of vtk-4.2.6 and vtk-5.0.0 are boths 'Slot=0'. Shouldn't they be slotted instead. People would have the opportunity to have both on their systems if required.
Ebuilds should only be slotted if the actual package installs in a slotted manner -- libraries, includes, everything, not if the maintainer needs to hack all over the place to slot it. GTK exemplifies this. I'm not sure what VTK does, I'm just saying the general philosophy.
Even though vtk could in principle be slotted with some effort I'd rather avoid having to maintain two separate packages, particularly since vtk is a fairly complex beast to build. Are you aware of any need (like backward incompatibility, etc.) that would require to keep the old 4.x tree around? Thanks, Markus
Markus, Thanks for your answer. VTK is used by Paraview and by OpenCascade (I think). From what I understand at the moment, these two packages are fairly wild beast as well and I suspect them to be fairly regarding to the version of VTK they are built against. This is a feeling but I think one can resonably consider that the murphy's law will apply to Paraview (at least) and that every single step will be a major victory... In this spirit, I think it will be very valuable to have working and slotted ebuilds for VTK (at least regarding 4.x vs. 5.x). VTK 4.0.x might be a bit old, but it would be nice to have VTK 4.2.x, VTK 4.4.x and VTK 5.0.x as maintained and working ebuild. I am very much aware that this is a major task. If you want, I can try to test and maintain the stuffs in collaboration with you. My knowledge about the arcanes of .ebuild is close to the absolute zero... I think it is time to learn. With the right documentation and some time, this should not be out of reach... ;) So, here is what I see: The ebuild for 4.2.6 does not work (see my bug report) The ebuild for 4.4.2 does not exist (I will try to build on top of what you did for 4.2.6) The ebuild for 5.0.0 exists. I did not try it. I have at my disposal here 2 machines to test things out: AMD64, gcc 3.4.5, glibc 2.3.6 x86 , gcc 4.1.1, glibc 2.4.0 So, what do you think? Daniel
Hello, Are you aware of the existence of this vtk-4.4.2 ebuild? I found it by "googling" a bit... http://www.3miasto.net/~ortylp/gentoo/sci-libs/vtk/ I am going to test it on my AMD64 machine and report here.
Well, this vtk-4.4.2 did not bring me very far on my AMD64 box: It can be said anyway that this ebuild has the merit to exist... -- Looking for C++ include strstrea.h -- Looking for C++ include strstrea.h - not found -- Looking for C++ include strstream.h -- Looking for C++ include strstream.h - not found -- Checking ANSI streams end-of-file bug level -- Checking ANSI streams end-of-file bug level - 0 CMake Error: Attempt to add link library vtkCommonPython which is not a library target to target 3 vtkFilteringPython CMake Error: Attempt to add link library vtkFilteringPython which is not a library target to target 3 vtkImagingPython CMake Error: Attempt to add link library vtkFilteringPython which is not a library target to target 3 vtkGraphicsPython CMake Error: Attempt to add link library vtkFilteringPython which is not a library target to target 3 vtkIOPython CMake Error: Attempt to add link library vtkGraphicsPython which is not a library target to target 3 vtkRenderingPython CMake Error: Attempt to add link library vtkImagingPython which is not a library target to target 3 vtkRenderingPython -- Configuring done !!! ERROR: sci-libs/vtk-4.4.2 failed. !!! Function src_compile, Line 62, Exitcode 255 !!! cmake configuration failed !!! If you need support, post the topmost build error, NOT this status message.
Same problems on my x86 box
Hi Markus, Can I rerequest that VTK could be slotted? A few of us have recently been working on installing and packaging OpenCascade and Salome for Gentoo, but they both fail to build with VTK 5. They will build with VTK 4.2.6, but I see it's just been dropped from portage, leaving us a bit stuck. OCC and Salome are very large packages, that aren't likely to upgrade to VTK 5 too quickly. I know this makes a lot of work for you, but it would be nice to have some serious solid modelling packages available in Gentoo, and I think we're close to getting them working. Thanks, Arthur Linkage: http://www.opencascade.org http://www.salome-platform.org http://forums.gentoo.org/viewtopic-t-492662.html
(In reply to comment #7) > Hi Markus, > > Can I rerequest that VTK could be slotted? > Hi Arthur, Thank you very much for your email and your work on opencascade and salome. That's great:) I removed vtk-4.2.6 because it is a fairly old release that wouldn't compile any more on any of my systems. I checked the webpages for opencascade and it doesn't list vtk as dependencies. Salome lists vtk-4.2.x; have you checked if it compiles against 4.4.2 which is the latest release of the vtk-4 branch? I am in principle open for slotting VTK, but only if the following points check out (none of which I have looked into at the moment): -Slotting a large library isn't necessarily a trivial matter and clearly more than just adding a SLOT=bla to the ebuild. There can be no clashes of libraries/file names between vtk-5 and vtk-4 during make install. Otherwise we have to hack the cmake files which I am not willing to do. -Also, I would only be willing to consider this if upstream will be maintaining vtk-4.x for at least some time to come, since I don't want to be the one to fix up the source when the next gcc upgrade brakes their c++ code. I'll have to have a look into this to see what is going on. Have you tried slotting vtk on one of your systems? Thanks, Markus
Hi Markus, Thanks for considering this. Firstly, my bad, OpenCascade doesn't need VTK in any version, I imagined that ;-) Daniel (also watching this thread) is doing the work on the OpenCascade ebuild, and making fast progress by the sounds on things. I haven't tried VTK 4.4.2, I'll check it out and report. If that builds okay, could we keep that in portage (or 4.2.6 if it doesn't), so we can at least keep the old version available for those that want it? I realise that slotting could be a big job, and agree that hacking cmake files isn't worth the effort. I don't know the upstream plans for VTK, but I'll have a look. I haven't tried slotting here - I can give it a go. Where would you start - do I simply install into a VTK4 directory, or is there something more subtle to it? As a nice alternative, Adam Erwan reports that he is working on a patch for Salome to use VTK5 (and gcc 4), so maybe this request will turn out to be redundant after all: http://www.salome-platform.org/forum/?groupid=10&forumid=9&thread=481&st=10
(In reply to comment #9) > I haven't tried VTK 4.4.2, I'll check it out and report. If that builds okay, > could we keep that in portage (or 4.2.6 if it doesn't), so we can at least keep > the old version available for those that want it? > I'd be ok with VTK-4.4.2. VTK-4.2.6 doesn't build on any of my dev machines any more and I can not, therefore, support it. > I realise that slotting could be a big job, and agree that hacking cmake files > isn't worth the effort. I don't know the upstream plans for VTK, but I'll have > a look. I haven't tried slotting here - I can give it a go. Where would you > start - do I simply install into a VTK4 directory, or is there something more > subtle to it? First of all, one needs to check if there are any file clashes in the way vtk installs itself on the filesystem. E.g. vtk-5.0.x install tons of stuff in /usr/lib/python2.4/site-packages/vtk/ and vtk-4.x might likely want to install on top of it which of course won't work. Even more difficult might be the libraries. Vtk-5.0.x provides, e.g. /usr/lib/libvtkWidgets.so. If vtk-4.x does the same we have a problem, since then they can't coexist on the system easily. > As a nice alternative, Adam Erwan reports that he is working on a patch for > Salome to use VTK5 (and gcc 4), so maybe this request will turn out to be > redundant after all: > > http://www.salome-platform.org/forum/?groupid=10&forumid=9&thread=481&st=10 > I personally think that this will be the way to go and let's hope that the salome devs are willing to take this step. Eventually they might have to anyway. Thanks, Markus
Markus, Vtk-5.0.2 is out, I don't know if you were aware of it. On portage, the latest is 5.0.1 Regards, Daniel
(In reply to comment #11) > Markus, > > Vtk-5.0.2 is out, I don't know if you were aware of it. > On portage, the latest is 5.0.1 > > Regards, > > Daniel > Hi Daniel, Yeah, I saw it, thanks for letting me know though :). I'll have a look at it sometime next week. Best, Markus
vtk-4.x is gone.
*** Bug 193972 has been marked as a duplicate of this bug. ***
Commenting on this one year old issue... > I'd be ok with VTK-4.4.2. VTK-4.2.6 doesn't build on any of my dev > machines any more and I can not, therefore, support it. 4.4.2 is still on the vtk webpage. It seems that they are aware that the big projects using VTK need time to adjust to VTK5. Salome 3 is still a VTK4 project (difficult to adapt besides, according to Erwan Adam, see http://www.salome-platform.org/forum/?groupid=10&forumid=9&thread=1592) and Salome 4 is not showing up... > > I realise that slotting could be a big job, and agree that hacking cmake files > > isn't worth the effort. I don't know the upstream plans for VTK, but I'll have > > a look. I haven't tried slotting here - I can give it a go. Where would you > > start - do I simply install into a VTK4 directory, or is there something more > > subtle to it? > > First of all, one needs to check if there are any file clashes in the way > vtk installs itself on the filesystem. > E.g. vtk-5.0.x install tons of stuff in /usr/lib/python2.4/site-packages/vtk/ > and vtk-4.x might likely want to install on top of it which of course won't > work. > Even more difficult might be the libraries. Vtk-5.0.x provides, e.g. > /usr/lib/libvtkWidgets.so. If vtk-4.x does the same we have a problem, > since then they can't coexist on the system easily. I think the VTK4-VTK5 issues have to be dealt with. It is definitely a show stopper (have prevented me from doing any valuable job with Salome for more than a year!) So, I think we need to slot VTK4 and VTK5. Besides, considering the murphy's law, I would not be surprised if a VTK6 would create the same kind of issues... So, we better be prepared... > > As a nice alternative, Adam Erwan reports that he is working on a patch for > > Salome to use VTK5 (and gcc 4), so maybe this request will turn out to be > > redundant after all: > > > > http://www.salome-platform.org/forum/?groupid=10&forumid=9&thread=481&st=10 It is _not_ redundant. My experience with Salome and the pain it is to compile with VTK5 is the proof. I have neither the time, nor the competence to dig in the code to chase the changes in object definitions and so on. Salome 3 has been developed for VTK4.4, not for VTK5.... > I personally think that this will be the way to go and let's hope that the > salome devs > are willing to take this step. Eventually they might have to anyway. Yes, Salome 4. When will it show up? I don't know... Daniel
(In reply to comment #15) > > I think the VTK4-VTK5 issues have to be dealt with. It is definitely a show > stopper (have prevented me from doing any valuable job with Salome for more > than a year!) > > So, I think we need to slot VTK4 and VTK5. Besides, considering the murphy's > law, I would not be surprised if a VTK6 would create the same kind of issues... > So, we better be prepared... > Hi Daniel, If vtk is slottable I could agree to doing this. However, (from what I have seen, I may be wrong) currently this is not possible since vtk4 and vtk5 will install on top of each other. Futhermore, there has to be some infrastructure to make sure packages find, compile, and link against the proper version. Hence, we had to fix up vtk by hand to make surethere are no collisions, which is something I currently don't have the resources to do. As a mater of fact, this slotting ability should really be taken care of by upstream. If the vtk community needs time to adjust to major releases they should push for such a slotting infrastructure. Do you know if this has been discussed? If not maybe fire up an email to their dev list and ask. It would be easier to keep different (non-slotted) versions of vtk around so people can chose which one the need. This won't work of course if users need both at the same time. If somebody submits a patch that does the slotting I'd be more than happy to look at it and see if it makes sense. If you desperately need vtk4 you could always do the slotting yourself (if it is possible) in your local overlay. Thanks, Markus
