Stab at an ebuild for the VTK toolkit, version 4.2 (<URL: http://public.kitware.com/VTK/index.php>) Notes: Probably should use flag-o-matic for the -mno-sse stuff. May use the 'doc' USE variable incorrectly -- currently it will download and install the html docs only if it's set. I don't think there's a better way to non-interactively configure the cmake system, but I really wish there were. Will add ebuild as an attachment.
Created attachment 15053 [details] ebuild for VTK-4.2
Created attachment 18940 [details] updated ebuild for vtk Sort of updated the ebuild for vtk to work on current installations. Cmake now needs -i to work, build depends on lang-tcl/tcllib and there is a subdir VTK inside the workdir. The rest remains unchanged.
Please read http://emu.gentoo.org/~liquidx/ebuildmistakes.html for some helpful tips.
Created attachment 26166 [details] ebuild for VTK 4.2.5 New ebuild for VTK 4.2. Changes since previous proposed ebuild: - Homapge is http://www.vtk.org - Download explicit version, not via a symlink to latest 4.2.x version. - Depends on dev-lang/tcl when tcltk USE flag is set. - Configuration oprions passed directly to cmake. - Contains local USE flag 'patented' (description: "Compile patented algorithms into VTK. Implies additional license for commercial use."). - Added path setup to /etc/env.d
Created attachment 26170 [details] VTK license/copyright
Created attachment 26459 [details] fixed ebuild for VTK 4.2.5 Previous version had broken installation. Should have double-checked what I'm posting. Fixed now. Changes from previous version: - Fixed installation. Now should install fine both with and without doc USE flag.
Created attachment 29518 [details] modified ebuild for vtk-4.4.2 This is a slightly modified ebuild for VTK interim release 4.4.2. It should also correct some symbolic link problems with the previous ebuild. However, as this is my first attempt at writing ebuilds, there is bound to be some problems (most likely in relation to the use doc flag).
*** Bug 49626 has been marked as a duplicate of this bug. ***
RE: vtk-4.4.2 I needed dev-lang/tk installed even without the `tcltk' flag set. Is this because of the Python/Tkinter bindings?
For some strange reason it fails to install Common/vtkAMRBox.h allthough other include files from Common get installed. Anyone an idea why?
Created attachment 34161 [details] modified ebuild for vtk-4.4.2 Now the "doc" USE variable will install the "vtkNightly" docs (there is no vtk-4.4.2 docs). Unfortunately, the md5sum of this doc set changes all the time, so someone may want to change this. I also added a USE variable "data" which installs the "VTKData" used in many examples, and I added a hack to fix vtkAMRBox.h not being installed. This is my first ebuild contribution, so criticism is gladly accepted.
The 4.2.5 ebuild doesn't work anymore because the download location has changed: ftp://public.kitware.com/pub/vtk/vtk4.2/moved_to_sourceforge/VTK-4.2.5.tar.gz (I couldn't find any files with explicit version numbers on sourceforge) Also, there seems to be a VTK-4.2.6.tar.gz available there too.
I build vtk-4.4.2 using +data -doc -patented +python +tcltk When I try to use the examples in the source tree, I get this error: nilok@aconite nilok $ cd src/VTK/Examples/Rendering/Tcl/ nilok@aconite Tcl $ vtk RenderLargeImage.tcl ERROR: In /var/tmp/portage/vtk-4.4.2/work/VTK/Hybrid/vtk3DSImporter.cxx, line 127 vtk3DSImporter (0x812b648): Unable to open file: /usr/lib/vtk/tcl/vtkbase/../../../../VTKData/Data/Viewpoint/iflamigm.3ds two things: 1) seems that $VTK_DATA_ROOT is set incorrectly which is strange because I see it specified in the ebuild! 2) it reports the error in /var/tmp/... which is a little annoying. Is that error information generated at compile time? I suppose it is since its a c++ file.
Created attachment 38216 [details] modified ebuild Still trying to fix a few bugs... see TODO at top of this ebuild. Also, not sure if this is really the most recent 4.2 version but the (new?) sourceforge project for vtk doesn't have version numbers: http://sourceforge.net/project/showfiles.php?group_id=106595
Created attachment 38226 [details] ebuild for VTK 4.2.6 Fixed the bug in VTKConfig.cmake (usr/include/vtk instead of /usr/include/vtk and other things like that)
It's been over a year since this was first submitted. Any chance this will be added to the portage tree soon?
Its still a bit buggy and I have very little experience with vtk. For example, I don't think java bindings work yet. Please test and let me know how it works for you!
It seems to work for me so far. Hopefully I'll be starting a new job soon using vtk. I'll have a better chance to really test it than.
Found one bug in the 4.2.6 ebuild. I have broken links in /usr/lib/python2.3/site-packages/vtk_python lrwxrwxrwx 1 root root 33 Sep 23 02:56 libvtkCommonPython.so -> usr/lib/vtk/libvtkCommonPython.so lrwxrwxrwx 1 root root 36 Sep 23 02:56 libvtkFilteringPython.so -> usr/lib/vtk/libvtkFilteringPython.so lrwxrwxrwx 1 root root 35 Sep 23 02:56 libvtkGraphicsPython.so -> usr/lib/vtk/libvtkGraphicsPython.so lrwxrwxrwx 1 root root 33 Sep 23 02:56 libvtkHybridPython.so -> usr/lib/vtk/libvtkHybridPython.so lrwxrwxrwx 1 root root 29 Sep 23 02:56 libvtkIOPython.so -> usr/lib/vtk/libvtkIOPython.so lrwxrwxrwx 1 root root 34 Sep 23 02:56 libvtkImagingPython.so -> usr/lib/vtk/libvtkImagingPython.so lrwxrwxrwx 1 root root 35 Sep 23 02:56 libvtkParallelPython.so -> usr/lib/vtk/libvtkParallelPython.so lrwxrwxrwx 1 root root 36 Sep 23 02:56 libvtkRenderingPython.so -> usr/lib/vtk/libvtkRenderingPython.so lrwxrwxrwx 1 root root 45 Sep 23 02:56 libvtkRenderingPythonTkWidgets.so -> usr/lib/vtk/libvtkRenderingPythonTkWidgets Basically, this diff fixes it: # diff vtk-4.2.6.ebuild vtk-4.2.6-r1.ebuild 119c119 < ln -s ../../../libvtk*Python*.so . --- > ln -s ../../../vtk/libvtk*Python*.so .
Confirmed the broken symlinks. Re-emerging with your fix. I don't understand how it will fix the problem: the symlinks point to "usr/lib/..." instead of "/usr/lib/..." (i.e. they are missing the leading slash). Anyway, we'll see tomorrow morning. Thanks for your help!
Your right, it doesn't fix it. I guess I'm confused about what portage is doing. I thought if I manually did it on the command line, and it worked, it should have the same result if portage did it. Why exactly are the symlinks broken when portage does it, but not when I do it manually?
As you point out, it didn't work. At least one problem is that on my system, it should be PYVER instead of PY_VER. I'm also testing it using dosym instead: # python are not installed by 'make install' if [ `use python` ]; then cd ${S}/Wrapping/Python docinto vtk_python distutils_src_install distutils_python_version # change PY_VER to PYVER (FINDME so I can search the log file) einfo "FINDME: ${PYVER} ${PY_VER}" LD_PATHS="${LD_PATHS}:/usr/lib/python${PYVER}/site-packages/vtk_python" # fix broken symlinks #cd ${D}/usr/lib/python${PYVER}/site-packages/vtk_python #ln -s ../../../libvtk*Python*.so . dosym /usr/lib/vtk/libvtk*Python*.so /usr/lib/python${PYVER}/site-packagers/vtk_python fi If this works, I'll upload my new version tomorrow. The comment "# fix broken symlinks" isn't mine: I don't know what happens if I simply comment out the lines after it. Should try that sometime I guess.
Created attachment 40814 [details] vtk-4.2.6-r4 What I described in the previous comment didn't work but the attached ebuild, vtk-4.2.6-r4, fixes the symlink problem.
Created attachment 42629 [details] vtk-4.2.6-r5.ebuild I've finished the ebuild, and tested it myself. Everything seems to be working now. here's the changes I've done: o PATH, and VTK_DATA_ROOT problems not apparrent anymore o java wrapping works now o added local use flags: example, expat, jpeg, mpi, png, tiff, zlib o fixed some style changes according to ebuild guide o FIXME: need to fix Examples/CMakeLists.txt to build other examples
4.2.6-r5 looks good! Couple of comments: Java bug: aconite portage # grep jar 4977-vtk-4.2.6-r5.log Building Java Archive /var/tmp/portage/vtk-4.2.6-r5/work/VTK/bin/vtk.jar... cp: cannot stat `/var/tmp/portage/vtk-4.2.6-r5/work/VTK/usr/bin/vtk.jar': No such file or directory chmod: cannot access `/usr/share/vtk/vtk.jar': No such file or directory So I guess this line cp ${S}/usr/bin/vtk.jar /usr/share/${PN} should be cp ${S}/bin/vtk.jar /usr/share/${PN} Also, I don't think there should be use flags for jpeg, png, tiff, zlib because those are supposed to enable or disable support for jpeg, etc. However, this isn't what happens for vtk: USE="-jpeg" emerge vtk still supports jpeg, it just uses internal libraries instead of the system ones. It looks like expat works like this too. I suggest we remove those use flags. Should the creation of the /etc/env.d file be done in postinst or preinst instead of install? (I *think* other packages do this but I don't really understand binary packages that well myself).
Created attachment 43536 [details] vtk-4.2.6-r5.ebuild I don't know how I missed that bug, anyway here's the fix. It actually should be cp ${S}/bin/vtk.jar ${D}/usr/share/${PN} chmod 644 ${D}/usr/share/${PN}/vtk.jar I asked about the env.d file on #gentoo-bugs, and they said it belongs in src_compile. Your explanation about the use flags sounds good enough for me, so I removed them. I was wondering why they weren't being used before:) One more change I've done. I'm pretty sure tcl/tk is required to compile vtk. So I made that a permanent dependecy, but I'm still using tcltk use flag for enabling tcltk wrapping?
You meant "belongs in src_install for the envd script right? I agree with you about the tcltk use flag. Something to check: does vtk use MPI exclusively for its parallel interface? If so, maybe it is appropriate to the "mpi" use flag instead of the "parallel" use flag?
Created attachment 43555 [details] vtk-4.2.6-r5.ebuild Yes, on your src_compile question. Added mpi support. It does actually use the mpi library, so the two use flags are seperate.
One thing I'm not sure about is whether we have the dependencies in the correct places (RDEPEND and DEPENT)? Should the tcl/tk dependency go into DEPEND?
If it *uses* tcl/tk to compile but isn't linked against it/use it at run time then put it in DEPEND. Also, I think sed should be added to DEPEND because we use that in the ebuild. I guess something like this: RDEPEND="tcltk? ( blah-blah/tcltk ) ...." DEPEND="${RDEPEND} blah-blah/tcltk sys-apps/sed ...." Presumably its ok that tcltk might be in DEPEND twice... Why is opengl and x11 a build-time but not a run-time dependency?
Created attachment 43560 [details] vtk-4.2.6-r5.ebuild >If it *uses* tcl/tk to compile but isn't linked against it/use it at run time >then put it in DEPEND. That's what I'm not sure about. I don't have enough experience with running vtk apps, so I 'm not sure whether all of these need to be run time depends as well. I think my new ebuild should be fine now. I just made all the dependecies part of DEPEND and RDEPEND except for cmake. >Also, I think sed should be added to DEPEND because we use that in the ebuild. I asked onto #gentoo-bugs about sed, and I was told anything in the system profile for the intended arch doesn't need to be included as a dependency. So I removed sed, and zlib.
do you know how to fix this: Calculating world dependencies \QA Notice: sed in global scope: media-gfx/vtk-4.2.6-r5 shows up when I emerge sync && emerge -vup world. Googled once, never found anything, maybe the repoman script would help? Ebuild looks good! and thanks for the info about sed. Seems I still have a lot to learn about ebuilds!
Are you using my ebuild? What used to cause it for me is this SHORT_PV=`echo ${PV} | sed -e "s/\(^[0-9]*\.[0-9]*\).*/\1/"` But since I replaced it with this. It now longer comes up for me MY_PV="$(get_version_component_range 1-2)" I've just been learning ebuilds myself over the last couple weeks. Reading the Ebuild Howto and 'man 5 ebuild' which seems more update. Plus, the people over at #gentoo-bugs seem to always have an answer for me.
Cool! yes your latest version fixed it. I will try to read of man 5 ebuild at some point.
Created attachment 45104 [details] vtk-4.2.6-r5.ebuild My understanding of dosed was wrong. I replaced this: dosed -i -e "s:${D}:/:g" /usr/lib/${PN}/VTKConfig.cmake with this: sed -i -e "s:${D}:/:g" ${D}/usr/lib/${PN}/VTKConfig.cmake
I'm been having problems with the doenvd part of src_install: Instead of this: doenvd ${T}/40${PN} I need this: dodir /etc/env.d doenvd ${T}/40${PN} otherwise I get this error: install: cannot create regular file `/var/tmp/portage/vtk-4.2.6-r5/image//etc/env.d/': No such file or directory See bug #77558.
Comment #36 no longer relevant. Its been fixed in portage-2.0.51-r12.
I'd really like to see this in portage, even if it has some issues. This probably belongs in sci-libs, so I'm reassigning. A few suggestions: 1. Local USE flags are generally discouraged, so I'd put 'data' in with 'examples', as some of the examples depend on VTKData. 2. The VTKDocHtml and VTKData links should be switched over to SourceForge. 3. You say that gcc-3.2.* has problems with SSE, but you're checking for glibc-3.2*. This doesn't make any sense. I'll submit a corrected ebuild in the near future.
Created attachment 52215 [details] vtk-4.2.6-r5.ebuild I applied the changes you mentioned. * switch all files to use sourceforge mirror * incorporated hybrid in the default compilation * moved data and example use local use flags to examples * fixed gcc check * i left parallel and patented as local use flags. parallel probably could be included in the default compilation, but patented probably has to stay as a local use flag
I can't get VTK to compile with gcc-3.4 (gcc-3.3 works fine). I get the same errors as here: http://public.kitware.com/pipermail/vtkusers/2005-January/077953.html Unfortunately, it looks like patching VTK to compile with gcc-3.4 would be non-trivial. So for now, we can simply reject gcc-3.4 using the gcc-major-version and gcc-minor-version functions from the toolchain-funcs eclass. Of course, if you can find a good patch, I'll gladly include it. The following issues should also be corrected in the latest ebuild: 1. Use toolchain-funcs (see above) for detecting gcc-3.2. Just because you have gcc-3.2 installed doesn't mean you're using it to compile VTK. 2. Resubmit the ebuild as text/plain, and get rid of the revision number (ie, name it vtk-4.2.6.ebuild). Revision bumps are typically something done only _after_ a package is in portage. Thanks for your help, and your quick response!
You might want to CC gcc-porting if you want help w/ porting to newer gcc.
Created attachment 52520 [details] vtk-4.2.6.ebuild I've made a few changes, so let me know if I've broken anything. I haven't had time do go through everything thoroughly, but it's looking better. VTK actually uses a plain BSD license, so I changed that line too.
Created attachment 52522 [details] vtk-4.2.6.ebuild I just switched the parallel use flag to threads. I tested it and all looks good.
Created attachment 52524 [details, diff] vtk-4.2.6-gcc34.patch Well, it looks like I was wrong. I thought there would be many gcc-3.4 problems, but only two files needed to be patched.
Created attachment 52525 [details] vtk-4.2.6.ebuild
Created attachment 52527 [details] vtk-4.2.6.ebuild Sorry, just a few more cleanups. I toned down the patent-warning language slightly, as I don't want to put Gentoo in the position of giving legal advice :-) I won't be around for the next few days, so maybe see what you can do about distcc and building the examples. Also, take a close look at what's installed ("equery files vtk"). I don't think we should leave *.cmake in /usr/lib/vtk. Thanks again for your help.
Re comment #38 about moving to sourceforge mirror. These files have no version numbers. Isn't that going to cause problems when 4.2.7 comes out? Won't portage just bail with md5sum errors? This is an upstream problem that I meant to tell kitware about but I probably forgot... :( Leaving the latest ebuild to emerge over night. Will take a look sometime tomorrow. Thanks for your interest, hope to see it in the tree soon!
I sent an email to Kitware requesting to use the complete version number on sourceforge. I don't use distcc myself, so I can't really test that feature.
I cannot reconfirm those distcc warnings (it was I who noted them in the first place). I build vtk using the new ebuild on both my laptop and desktop using distcc without problems. Perhaps when I reported that warning, my gcc versions didn't match? Anyway, lets not worry about it, if it shows up again, I'll file another bug. The switch from (data, example) to examples missed the following line: use data && echo "VTK_DATA_ROOT=/usr/share/${PN}/data" >> ${T}/40${PN} which should read: use examples && echo "VTK_DATA_ROOT=/usr/share/${PN}/data" >> ${T}/40${PN}
I've got troubles with this last build. It doesn't link properly against the various GL functions. I haven't had the time to investigate this properly, but I suspect it might have something to do with either that I use xorg-x11 or ati-drivers. I've had the same build working properly on another machine, but that machine had nvidia and XFree, and if I remember correctly gcc33. Anyway, just wanted to warn you about it, I'll tell you more if it hasn't been fixed before I get the time to investigate, probably sometime during the next week.
Just a though, could bug 68926 be the problem?
If you could provide the exact error message(s) and when in the compile process they occur, as well as the output of: opengl-update --get-implementation ...it would be appreciated. I've had no trouble compiling and linking against the NVidia OpenGL libs, and I'm currently in the process of compiling (with no errors so far) after running opengl-update xorg-x11.
I'm sorry, I got a little short on time. Anyway I returned to trying to build vtk again yesterday, and now it just works. I'm suspecting updated ati-drivers could have some saying in this matter, but anyway, no need to fix something that runs. I'll return if things go wrong again.
Hmm, maybe i'm doing something wrong, but when i try to emerge vtk using the 4.2.6.ebuild from http://www.gentoo.de/viewcvs/sci-libs/vtk/ i get: Calculating dependencies ...done! >>> emerge (1 of 1) sci-libs/vtk-4.2.6 to / >>> md5 files ;-) vtk-4.2.6.ebuild >>> md5 files ;-) ChangeLog >>> md5 files ;-) files/digest-vtk-4.2.6 >>> md5 files ;-) files/vtk-4.2.6-gcc34.patch >>> md5 src_uri ;-) VTK-4.2-LatestRelease.tar.gz >>> Unpacking source... >>> Unpacking VTK-4.2-LatestRelease.tar.gz to /var/tmp/portage/vtk-4.2.6/work * Applying vtk-4.2.6-gcc34.patch ... [ ok ]>>> Source unpacked. /usr/lib/portage/bin/ebuild.sh: line 2: -O: command not found Help argument "," is not a CMake command. Use --help-command-list to see all commands.
By the way: I've forgot to say that I use cmake 2.0.5
But i get exactly the same with cmake-2.0.6
I'm committing this. If you still have a problem building VTK after syncing, please file another bug. This error: /usr/lib/portage/bin/ebuild.sh: line 2: -O: command not found indicates you might have some problem with portage. If you still get the error, re-emerging portage can't hurt.
You might have something uncommented or bad syntax in make.conf or files in /etc/portage.
Hmm, I still think it is possible that it is my fault that this problem appears, so I will summarize what I have done after I read your advices: 1.) I checked make.conf, package.(mask/keywors/use) for possible errors. Everthing seems to be ok, as far as I can tell ... 2.) emerge sync; Afterwars I tried to emerge vtk again - which led to the allready described error message. 3.) I visited http://gentoo-wiki.com/HOWTO_Installing_3rd_Party_Ebuilds. Inspired by what i've read I removed everthing but the ebuild file from sci-libs/vtk and 'ebuild vtk-4.2.6.ebuild digest'. After some downloads I tried to emerge vtk again - as you might expect without succes, as the gcc-3.4 path file was missing. So I inserted it from http://www.gentoo.de/viewcvs/*checkout*/sci-libs/vtk/files/vtk-4.2.6-gcc34.patch?rev=HEAD&content-type=text/plain and 'ebuild vtk-4.2.6.ebuild digest' again. After that I was where I've started. 4.) I 'emerge portage', which reinstalled version 2.0.51.19 and tried again - with the old results.
Well, I'm sorry: Just after submitting my last comment I realized that vtk has just been added to the official portage tree, while I was still fooling around with my portage overlay: Thus I removed my 'custom ebuild' and 'emerge vtk'. It is beeing compiled right now as I write this message, and I hope that I wont't regret sending my message before it is complete. Sorry for bothering you with obscure problems.
Created attachment 64079 [details] new vtk4.4 ebuild a new ebuild for vtk 4.4, then 4.2 is too old.
Created attachment 64392 [details] vtk-4.4.2.ebuild it has a little bug! The dependencies for Rendering/vtkFreetypeFontCache.o aren't okay. I must editing the file VTK/Rendering/vtkRendering.dir/vtkFreetypeFontCache.o.build.depend and add follow lines Rendering/vtkRendering.dir/vtkFreeTypeFontCache.o: Utilities/freetype/vtkfreetypeConfig.h Rendering/vtkRendering.dir/vtkFreeTypeFontCache.o: Utilities/ftgl/vtkftglConfig. h I've no idea why. I hope anyone can fixed this bug.
