InsightToolkit +universal is not universal

[ryandesign@…]

Building InsightToolkit with the +universal variant on Snow Leopard with universal_archs set for x86_64 i386, I only get files compiled for x86_64. Please either fix the universal variant or disable it.

$ port provides /opt/local/lib/InsightToolkit-3.16/libITKCommon.dylib
/opt/local/lib/InsightToolkit-3.16/libITKCommon.dylib is provided by: InsightToolkit

$ port installed InsightToolkit
The following ports are currently installed:
  InsightToolkit @3.16.0_1+doc+py25+shared+universal+wrap (active)

$ lipo -info /opt/local/lib/InsightToolkit-3.16/libITKCommon.dylib
Non-fat file: /opt/local/lib/InsightToolkit-3.16/libITKCommon.dylib is architecture: x86_64

[dweber@…]

$ port variants InsightToolkit
InsightToolkit has the variants:
   brainweb: provide ITK BrainWeb data in /opt/local/share/InsightToolkit-3.16/data
[+]doc: provide doxygen documentation in /opt/local/share/InsightToolkit-3.16/doc
   examples: provide ITK examples in /opt/local/share/InsightToolkit-3.16/examples
   py24: python 2.4 wrapper (includes wrap)
     * conflicts with py25
     * requires wrap
[+]py25: python 2.5 wrapper (includes wrap)
     * conflicts with py24
     * requires wrap
   shared: build shared libraries
   testing: provide ITK testing in /opt/local/share/InsightToolkit-3.16/testing
   universal: Build for multiple architectures
   wrap: USE_WRAP_ITK for external language support (includes shared)
     * requires shared

$ port file InsightToolkit
/opt/local/var/macports/sources/rsync.macports.org/release/ports/graphics/InsightToolkit/Portfile

$ grep -c universal /opt/local/var/macports/sources/rsync.macports.org/release/ports/graphics/InsightToolkit/Portfile
0

So, you see, there is no explicit definition for the universal variant in the Portfile for the InsightToolkit port. This variant is defined by the port system. Perhaps this ticket should be targeted elsewhere?

Take care, Darren

[ryandesign@…]

Replying to dweber@…:

Perhaps this ticket should be targeted elsewhere?

No, it should not. MacPorts defines a default universal variant that works for many ports. For those like insightToolkit where it does not, the individual port should override it and make it work. Or, if that's not possible, the port should disable the universal variant.

[dweber@…]

I wonder what it is about the universal variant that does not work with InsightToolkit. Is it that InsightToolkit is using cmake for the build and the universal variant does not set the right options for cmake (or cmake does not accommodate a universal build)?

Are there specific examples of other ports where the universal variant does not work and they override it to get it working?

[ryandesign@…]

Replying to dweber@…:

I wonder what it is about the universal variant that does not work with InsightToolkit. Is it that InsightToolkit is using cmake for the build and the universal variant does not set the right options for cmake (or cmake does not accommodate a universal build)?

Absolutely. The default universal variant is designed for software that uses autotools-type configure scripts. For software that uses cmake, we have the cmake portgroup which takes care of the differences in the cmake build system and includes its own universal variant.

Are there specific examples of other ports where the universal variant does not work and they override it to get it working?

Sure, lots. You can grep the dports directory for "variant universal" to see many of them. But I'd try using the cmake portgroup first as it may "just work".

[jmr@…]

If it's too hard to get universal working, all you need to do to fulfil Ryan's request is add universal_variant no.

[dweber@…]

Will look into it soon, thanks for the tips.

This port is a huge build. Can this modification wait until we have a new release version, instead of making this minor change in a revision? The upgrade process seems hardly worth it for this.

[dweber@…]

OK, should be fixed in r63811