Trying to update a Portfile

[Harry van der Wolf]

2010/7/22 Ryan Schmidt <ryandesign at macports.org>

> On Jul 21, 2010, at 08:35, Harry van der Wolf wrote:
>
> > Thanks for your reply. I was already typing a mail to mention that I had
> found it. I "grepped" for other Portfiles having "sourceforge:".
> >
> > I came to:
> > master_sites            sourceforge:hugin
>
> Since ":${name}" is appended by default, you can simplify this to
> "master_sites sourceforge"
>
> > distname                $name-$version.$revision
>
> As Joshua said, do not include ${revision} here. It is expected that
> revisions can be incremented independently of upstream changes to distfiles.
> So in this case I guess you need to use "distname ${name}-${version}.0". Or
> leave distname alone and set "version 2010.0.0" if that's an accurate
> version number. (I didn't quite understand why there was an extra ".0" at
> the end of the distfile name.)
>
> Note also that these questions are more appropriate for the macports-dev
> mailing list.
>
>
>
>
Thanks for your helpful replies.

I had forgotten about the macports-dev list (I don't want to be a dev
anyway, I prefer to be an end user but in that case nothing might happen :-)
) .

I could start another thread now on the macports-dev list but I want to ask
one hopefully final question:
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).

Harry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20100722/a52217ad/attachment.html>