vigra 1.9.0

[BSeppke (Benjamin Seppke)]

This will update the vigra port (cat: graphics) to version 1.9.0. The new version of this powerful computer vision libraries introduces a lot of new functionality!

Due to new template mechanisms, this version of the vigra needs macports to be built with an XCode of Version >= 4.0. I also tested the use of the macports gcc - instead of XCode's llvm/clang-compilers. macports' gcc of version >= 44 seems to compile the vigra too but the compiled import/export libraries result in segfaults when called. Thus I suggest, to use only XCode at version > 4 in future. The existence of XCode is also performed inside the Portfile. E.g. Snow Leopard @ XCode v3 will not be supported with this release.

Please not that this update of the port has some special other enhancements:

1. It automatically resolves the issue described in ticket #38024

2. It asks the user if and if yes, which python2X (vigranumpy) bindings shall be installed. Since the vigranumpy-bindings require boost being compiled with exactly the same python python2X version, this portfile does not only check for the existance of libboost_python but also for the linked python version of the libboost_python. (default +python26)

3. Replaced dependency of fftw3 to fftw3-single, since vigra is now working with this lib.

4. Due to clang/llvm-compiler issues a new patch is needed, to successfully compile the vigra. This patch (patch-include-vigra-accumulator-grammar.hxx.diff) has to be placed inside the files-subdirectory.

I hope, that we can manage to update the Port quickly. I tested this port successfully at the following environments: + Mac OS X SL 10.6.8 (XCode 4.2) + Mac OS X ML 10.8.2 (XCode 4.6)

[cooljeanius (Eric Gallager)]

E.g. Snow Leopard @ XCode v3 will not be supported with this release.

Can Snow Leopard users with Xcode 3 have a separate vigra18 port? i.e. the current vigra port would become vigra18 and then your update to 1.9.0 would become the regular vigra.

[mf2k (Frank Schima)]

Please do not change the $Id: line in the Portfile.

[larryv (Lawrence Velázquez)]

Replying to benjamin.seppke@…:

Due to new template mechanisms, this version of the vigra needs macports to be built with an XCode of Version >= 4.0. I also tested the use of the macports gcc - instead of XCode's llvm/clang-compilers. macports' gcc of version >= 44 seems to compile the vigra too but the compiled import/export libraries result in segfaults when called. Thus I suggest, to use only XCode at version > 4 in future. The existence of XCode is also performed inside the Portfile. E.g. Snow Leopard @ XCode v3 will not be supported with this release.

Does vigra actually use Xcode to build, or are you restricting on Xcode version as a proxy for compiler selection? If the latter, please use compiler.blacklist or compiler.whitelist instead, and possibly the compiler_blacklist_versions PortGroup​ if you have to select based on compiler versions. Feel free to ask if you need help with using them, as they are currently undocumented.

2. It asks the user if and if yes, which python2X (vigranumpy) bindings shall be installed. Since the vigranumpy-bindings require boost being compiled with exactly the same python python2X version, this portfile does not only check for the existance of libboost_python but also for the linked python version of the libboost_python. (default +python26)

I strongly suggest using the active_variants PortGroup​, if you want to check for a certain variant of boost. It will simplify the portfile considerably.

[BSeppke (Benjamin Seppke)]

First of all, I'd like to thank you all for your helpful comments!

I now force the use of a clang or llvm-compiler using the compiler.blacklist enviroment. Additionally, I use the provided active_variants portgroup to ensure that boost has been installed with the correct +python2X variant. BTW: This Portgroup was all I was searching for and should definitely be mentioned in the FAQ and/or documentation!

I also agree, that we should move the "old" vigra port to a new port vigra18, in order to provide a working version of vigra to all XCode 3.2.6 users on Snow Leopard. In my opinion, it's completely unfair that Apple provides the XCode 4.2 download for Snow Leopard only for paid developer-accounts.

I hope that the replaced Port and corresponding diff-files will make it to the update of vigra to version 1.9.0.

Best wishes, Benjamin

[BSeppke (Benjamin Seppke)]

If there are no more improvements on the Port I submitted earlier - could someone with the correct writing rights perform the changes inside the ports-repo?! Unfortunately, I am not allowed to make any changes there.

vigra -> vigra18

vigra of this thread -> vigra

Kind regards, Benjamin

[ryandesign (Ryan Carsten Schmidt)]

Why should a vigra18 port be created? Why is Xcode >= 4 required for vigra 1.9? Is it because of the compiler? If so, could you use a macports clang port to allow compilation on earlier systems? You're already blacklisting everything except clang so MacPorts will probably already try to use a MacPorts clang compiler on old Xcode versions (i.e. those in Leopard and Tiger) that don't have llvm.

The default python should probably be python27, and only if another python variant has not already be selected. See wiki:PortfileRecipes#default_variants. The python28 and python29 variants should be deleted because no such versions of python will ever exist. (Python development is focused on version 3 now.)

[larryv (Lawrence Velázquez)]

Replying to ryandesign@…:

You're already blacklisting everything except clang so MacPorts will probably already try to use a MacPorts clang compiler on old Xcode versions (i.e. those in Leopard and Tiger) that don't have llvm.

I don’t think that’s made it out of trunk yet, if I’m not mistaken.

source:branches/release_2_1/base/src/port1.0/portconfigure.tcl#L445​

[ryandesign (Ryan Carsten Schmidt)]

As yes, you're right, so then my question is even more pertinent than I thought it was.

[BSeppke (Benjamin Seppke)]

So... to conclude, i submitted an updated version of the Portfile and the corresponding diff-file.

I also tried the macports clang, which is AFAIK clang-2.9 and it works. With this result, we should be able to keep the vigra port as it is and don't need another vigra18 port.

Regarding the compilers, I'm a bit unsure how to handle it right. What I did is to put all clang and llvms on the compiler whitelist. I hope that this is sufficient to force the build using a correct compiler.

Additionally, I restricted and simplified the python dependencies to python26 and python27.

Please let me know, if there are any more improvements needed...

[ryandesign (Ryan Carsten Schmidt)]

Replying to benjamin.seppke@…:

I also tried the macports clang, which is AFAIK clang-2.9 and it works. With this result, we should be able to keep the vigra port as it is and don't need another vigra18 port.

As you know (because you've listed them in the diff), MacPorts offers ports for clang-2.9, clang-3.0, clang-3.1, clang-3.2, and clang-3.3.

Regarding the compilers, I'm a bit unsure how to handle it right. What I did is to put all clang and llvms on the compiler whitelist. I hope that this is sufficient to force the build using a correct compiler.

We can fix this up. You either want to use compiler.whitelist or compiler.blacklist. compiler.whitelist means "you may only use these compilers, no others". compiler.blacklist means "you may use any compilers except these". IIRC if you specify compiler.whitelist, compiler.blacklist is not used.

Also, there is a scary-looking block of code that we need to add (we can copy it from another port) to get the correct compiler dependencies added. This block will no longer be needed as of MacPorts 2.2.

Please let me know, if there are any more improvements needed...

"-DCMAKE_VERBOSE_MAKEFILE=ON" is listed three times in configure.args?

The comment about Xcode >= 4 still doesn't make sense to me. Xcode 3.2.6, the last free version for Snow Leopard, does include a version of clang and llvm-gcc-4.2, and the compiler.whitelist line you wrote will allow them to be used. I have not tested if either of them compile vigra successfully. If it is known that they will not work, then they should be blacklisted (or not whitelisted).

[ryandesign (Ryan Carsten Schmidt)]

Also, there's a post-destroot block in the Portfile (which has been there before your changes) with a comment starting "fix location of documentation to include version". We don't want documentation directories to have the version in their name; we tried that several years ago but decided it was not a good idea. So this should be changed with this update.

[BSeppke (Benjamin Seppke)]

Replying to ryandesign@…:

Also, there's a post-destroot block in the Portfile (which has been there before your changes) with a comment starting "fix location of documentation to include version". We don't want documentation directories to have the version in their name; we tried that several years ago but decided it was not a good idea. So this should be changed with this update.

Okay, I fixed this with the latest files I uploaded earlier!

[larryv (Lawrence Velázquez)]

Replying to ryandesign@…:

IIRC if you specify compiler.whitelist, compiler.blacklist is not used.

Weirdly enough, this is not true. If present, compiler.whitelist just displaces compiler.fallback. So one can theoretically specify a whitelist and then negate parts of it with a blacklist. I guess this could be useful in some sort of restrictive variant.

source:branches/release_2_1/base/src/port1.0/portconfigure.tcl#L425​

[BSeppke (Benjamin Seppke)]

What about not using the compiler blacklist or compiler whitelist. I suggest another approach to check and reload macport's-clang-2.9 for compilation:

if {![regexp "llvm" ${configure.compiler}] && ![regexp "clang" ${configure.compiler}]} {
    depends_build-append clang-2.9 
    configure.compiler   macports-clang-2.9 
}

What do you think about that script? Independently of this issue, we should perform the port update as soon as possible. There are some guys waiting for the next version ;)

Best wishes, Benjamin

[larryv (Lawrence Velázquez)]

I just noticed that builds using cmake. You might want to look into using the cmake​ PortGroup.

[BSeppke (Benjamin Seppke)]

To hopefully end up this discussion, I added the test for clang or llvm to the portfile. Additionally, I added the Portfile to the PortGroup cmake and used a lot of the predefined cmake parameters there.

I hope, that this Portfile makes it to the repository, finally. Could someone please update the existing Portfile?!

Best wishes, Benjamin

[larryv (Lawrence Velázquez)]

Why do you have both a whitelist and a blacklist? Which compilers, specifically, do not work?

[ryandesign (Ryan Carsten Schmidt)]

If none of the Xcode compilers are suitable, and you want to use a MacPorts clang compiler instead, use the newest stable one that will work. The newest stable is currently clang-3.2.

Using [string match] is better than using [regexp] when you're not actually using a regular expression.

[BSeppke (Benjamin Seppke)]

Let me just answer the last two comments on this issue:

Q1: Why do you have both a whitelist and a blacklist? Which compilers, specifically, do not work?

A1: Since whitelist + blacklist = all compilers, that should make no difference. However, there seems to be some confusion about using the whitelist/blacklist env. (see above in this thread). All compilers of the black list do not work. (gcc >= 4.4 compiles, but results in non-working image import/export-libraries).

WORKING: Everything coming with XCode >= 4.0 and clang >=2.9 (llvm resp.)

NON-WORKING: Anything else...

Q2: If none of the Xcode compilers are suitable, and you want to use a MacPorts clang compiler instead, use the newest stable one that will work. The newest stable is currently clang-3.2.

A2: The XCode >=4.0 compilers work, hoewever XCode 3.2.6 (the latest freely available for SnowLeopard) won't work!

[BSeppke (Benjamin Seppke)]

To close this discussion and hopefully to update this port I finally decided to remove the white and blacklists for the compilers. The port now checks if ther is *any* clang or llvm compiler and if uses the one it found. If not, the clang-3.2 port is added as a build dependency and will be used by cmake to build to vigra.

I also replaced the rexexp's by string matches functions.

[larryv (Lawrence Velázquez)]

Replying to benjamin.seppke@…:

To close this discussion and hopefully to update this port I finally decided to remove the white and blacklists for the compilers. The port now checks if ther is *any* clang or llvm compiler and if uses the one it found. If not, the clang-3.2 port is added as a build dependency and will be used by cmake to build to vigra.

What about the macports-dragonegg-* compilers?

[BSeppke (Benjamin Seppke)]

Replying to larryv@…:

What about the macports-dragonegg-* compilers?

I just tested it - as I assumed it didn't work. Since dragonegg-* relies on the gcc47 it produces the some non-working import/export libs. I could figure out exactly the same behaviour like gcc47 for dragonegg-3.2 e.g.

[BSeppke (Benjamin Seppke)]

without black or whitelists, just does what it should do...

[BSeppke (Benjamin Seppke)]

without black or whitelists, just does what it should do...

[BSeppke (Benjamin Seppke)]

I tried all MacPorts-clang compilers yesterday evening and today...

And I have to admit, that only clang-2.9, clang-3.0 and clang-3.1 are able to compile the library. The others result in compiler errors. Thus I changed the Portfile again to select macports-clang-3.1 if XCode < 4 is installed or the default compiler...

Maybe it is now easier to use the blacklist functionality again?

[BSeppke (Benjamin Seppke)]

Since there have not been any comments within the last two months, I propose to use the provided Portfile and update the vigra port to version 1.9.0. At the institute where I work we use this package for installation on various iMacs and it didn't raise any problems. So, could somebody with svn-rights to the macports repository please perform this update. As I mentioned earlier (might even be at the initial comment), there are a lot of people outside waiting for this update-step...

Best wishes, Benjamin

[neverpanic (Clemens Lang)]

Sorry for the delay in getting this committed. I wonder why none of the people that gave you feedback finally got around to committing this.

It's in r110687. I changed the compiler selection construct to a single call of compiler.blacklist that will blacklist all versions of gcc, dragonegg and clang from Xcode < 4. MacPorts will automatically fall back to macports-clang-3.2 on systems without a useable Xcode compiler in that case and will automatically ensure the correct dependencies are in place since 2.2.

If a ticket like this get stalled again, consider dropping a mail to macports-dev to revive it.