bump vigra to 1.7.1

[michaelld (Michael Dickens)]

Vigra has progressed somewhat since 1.6. Here's a Portfile patch to augment it to 1.7.1; I've included some variants that are now available, though maybe they should just be always used? The 'numpy' one does not work yet, since I could not find a way to install Boost::Python -- so I commented out that variant's code for now. This change might fix ticket #25315.

[michaelld (Michael Dickens)]

"svn diff" in "vigra" directory; bump from 1.6 to 1.7.1 including the necessary move to CMake.

[michaelld (Michael Dickens)]

Moving to vigra 1.7.1 also allows 'lprof' to use it instead of an internal vigra version that doesn't work well with the new libpng14.

[michaelld (Michael Dickens)]

See ticket #25315.

[BSeppke (Benjamin Seppke)]

diff of currently active (vigra 1.6.0) and proposed new (vigra 1.7.1) port

[BSeppke (Benjamin Seppke)]

I submitted a proposed new Portfile by means of a diff to the original Portfile. As mentioned by Michael, I also found no way to make the vigranumpy-binding dependant to boost::python, as this is a (non-default) variant of boost. However, when installing the numpy bindings without having boost::python installed a priori an error will arise because some files will not be found...

Unfortunately, the install process puts the wrong RPATHs inside the dylibs (/opt/local/lib/PYTHON_EXT.so instead of ...Frameworks/Python...../site-packages/vigra/PYTHON_EXT.so), so I had to correct this using some ugly "install-name-tool" system calls. Please tell me, if there is another way to do this. I tried nearly every CMake-swith I found, but none fixed this...

Someone with the necessary rights should update the port to the proposed new version. I tried, but am not allowed to commit to svn :-( Replying to michaelld@…:

Vigra has progressed somewhat since 1.6. Here's a Portfile patch to augment it to 1.7.1; I've included some variants that are now available, though maybe they should just be always used? The 'numpy' one does not work yet, since I could not find a way to install Boost::Python -- so I commented out that variant's code for now. This change might fix ticket #25315.

[michaelld (Michael Dickens)]

Let me give you changes a shot & see what happens. I know that Python .so file self-id's are OK to not include path and such (same happens for Qt4 plugins; Qt actually provides a specific type where further linking to the resulting plugin isn't supposed to happen). Otherwise, yeah, it's possible that the Python linking is messed up. Do you want me to post my changes (to the original Portfile) for you to check out one last time, or just go ahead and check them in once it's working for me?

[BSeppke (Benjamin Seppke)]

Okay, just to summarize, what I found out (about the python-bindings)

1. Newest CMake needed: You need the newest CMake, in older versions, just the python26 lib will be found, with the newest version CMake is able to find 27 libs.

2. Boost::Python: The boost::python libs have to be installed by the user before the installation of vigranumpy. As the Boost::Python is just a variant of boost, we cannot add a dependency to this one.

3. Installation of vigranumpy's .so files I: By default, the installed vigranumpy-libs have a wrong install-name-id (at least on my maschine) of "/opt/local/lib" NAME...

4. Installation of vigranumpy's .so files II: The vigranumpy python extensions are all linked to vigranumpycore.so. However, these internal links are of the wrong prefix "/opt/local/lib" (for the default case).

I hope, that my proposed Portfile fixes the issues 3-4, I tested it at 10.6 with +python27 variant... So, if it also works for you, I think we should bring the new Portfile online. As you mentioned earlier, the new vigra has to offer a lot more, and the python bindings are a great thing, more than nice to have (if you'd asked me).

[michaelld (Michael Dickens)]

I'm attaching YA diff. Comments:

1. We cannot control which version of CMake is installed; but, MacPorts installs a compatible version for finding Python 2.7+, so we can safely ignore this issue.

2. I've added a check for the Boost::Python library, which:

a) if not found, disabled the +numpy variant.

b) if found, determines the Python version and allows a +numpy variant that will add dependencies with numpy and sphinx of the correct Python persuasion.

3.&4. I've added a patch to correct the INSTALL_NAME_DIR for the Python .so files, if installed. !@#$ CMake does not make this easy, and, really, is quite stupid about how it makes this determination -- if setting the "self-id" for a library, it should be either (1) the same as the file; or (2) just the filename (no path). It should -never- be some other path. No idea what happens when the self-id -is- some other path though ...

Give this version and whirl & let me know how it goes.

[michaelld (Michael Dickens)]

svn diff" in "vigra" directory; 3rd try now ...

[michaelld (Michael Dickens)]

Note: revert the vigra/Portfile to its original state before applying this patch. Make sure the "files/..." is created and the patch exists -- sometimes you have to create the "files" directory first IME.

[BSeppke (Benjamin Seppke)]

I just tried out your new version. It works fine, thank you for writing that tiny patch on the VIGRANUMPY-cmake file! Would you mind checking in the new version into the macports repository? I think we are fine with your latest version.

Just before I forget it, in your latest diff you omitted the checksums:

checksums patch-config-VIGRA_ADD_NUMPY_MODULE.cmake.diff \

md5 1ddb74188cf4aff8527f2df274231628 \ sha1 d88fbab9c959a9dfdd458efa9455cc805615205c \ rmd160 6c46fc59bf415d9b43371dff1eb9552e416e6d3b \ vigra-1.7.1-src.tar.gz \ md5 2bde208e0fd7626770169dd4fa097282 \ sha1 f90f54da31a6544057c25df7dbcc6954604de079 \ rmd160 67a27b11f3d844b01fd8f2b0d2fe761099f8170b

You should add these before submitting..

And - just again - thank you for your work!

[michaelld (Michael Dickens)]

Done in r75495. You're welcome & thank you for being so responsive!