[63983] trunk/dports/graphics/InsightToolkit/Portfile

[Ryan Schmidt]

On Feb 19, 2010, at 19:12, Darren Weber wrote:

> It was a build-time dependency, but I changed it to a lib-dep because cmake contains Modules in
> 
> /opt/local/share/cmake-2.8/Modules/
> 
> Whenever cmake is upgraded, the path to these modules may change and the InsightToolkit should build again to modify some of those module files, like FindITK.cmake.  This re-build is very expensive in order to run just the post-destroot phase of InsightToolkit, but it's the only way to get those module changes (at this time).
> 
> Perhaps a new port that only modifies the cmake modules for InsightToolkit is the way to go?  This new port could have a lib-dep on cmake, while InsightToolkit could have a build-dep on it.

But are those modules used by InsightToolkit at runtime? If so, it should be a library dep on cmake. If not, it should be a build dep. It doesn't really have anything to do with whether updating cmake causes that path to change, except that if it does, and if those modules are used by cmake's dependents at runtime, then the revision of those dependents must be increased to force a rebuild. I didn't see any part of InsightToolkit dynamically linking to anything in that directory, using "otool -L", but it could be dlopening or reading those files in other ways that I can't check.