On Fri, Mar 30, 2012 at 10:10:16PM -0500, Ryan Schmidt wrote: > With the way you've had to basically run the patch, build and destroot > tasks a second time each in order to do this, it feels like maybe this > would be an ideal opportunity to use a subport instead. I don't know > the freeimage software however. Presumably, since the port didn't have > freeimageplus before this change, there are uses that don't require > freeimageplus. Does changing this to a subport sound ok? If so I can > give it a try.
FreeImagePlus is a C++ wrapper around FreeImage. I agree piggy-backing this into the freeimage port isn't the cleanest solution, but it's not easily splitted either, because from what I have seen both Makefiles will actually build the freeimage dylib (and install some conflicting header files). Factoring this out into a separate port (or subport for that matter) would require patching of the Makefile to prevent building and installing the freeimage dylib a second time, but rather only link against the one installed by freeimage. So since FreeImagePlus is only a small addition I think it's more suitable for a variant, and since we cannot depend on variants and FI+ is actually something other ports might want to depend on and it's not much overhead to compile FI+, I went this way to add it in. If you want to work on it, feel free to, though. -- Clemens Lang _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
