Trying to update a Portfile
Ryan Schmidt
ryandesign at macports.org
Thu Jul 22 02:26:44 PDT 2010
On Jul 22, 2010, at 04:20, Harry van der Wolf wrote:
> The resulted build, both hugin itself as the hugin dylibs, don't have the correct path when questioned with the "otool -L <bin or lib>". They do for the "external" libraries they are linked to like libjpeg etc.
> Both the binary and it's own libraries are "pathless" instead of mentioning "/opt/local/lib/<dylib>". It means that the binary can't find the libraries and the libraries can't find the other hugin libraries anymore.
> what options do I have:
> - Is there a Macports setting to enable/force this
> - Is there a MacPorts setting to run the install_name_tool (some post build option?)
> - should I use the libtool "-install_name" option
> - should I patch hugin, either directly of via the libtool option
>
> I can come up with a few other options but if MacPorts has a nice one that would be the preferred solution.
>
> (I did not have time yet to build a straight "no Macport" cmake build to see if that suffers from the same. It didn't in the past, but maybe I really have to patch the hugin CMakeList.txt files for the OSX builds before patching MacPorts).
If you're building with cmake, you should be using the cmake portgroup which takes care of this for you. Add to the portfile beneath the "PortSystem 1.0" line the line "PortGroup cmake 1.0". Then remove the things which this portgroup takes care of for you, which are "depends_build port:cmake", "configure.cmd cmake", "configure.pre_args", "configure.args -DCMAKE_INSTALL_PREFIX:PATH=${prefix}". If you need to set additional configure.args, be sure to use configure.args-append so you're not overwriting the portgroup's configure.args.
More information about the macports-users
mailing list