[107333] trunk/dports/gnome/anjuta

[Ryan Schmidt]

On Jun 25, 2013, at 23:38, David Evans wrote:
> On 6/25/13 9:17 PM, Ryan Schmidt wrote:
>> The port is apr-util, not apr-utils. But does anjuta actually use apr, apr-util and neon? Aren't they just used by subversion? If so, these should not be listed as dependencies of anjuta.
>> 
>> If you were basing these dependencies on the output of `otool -L` with ports built with MacPorts 2.1.x or earlier, note that MacPorts 2.1.x and earlier overlink to libraries, so the output of `otool -L` often shows libraries that aren't needed. This is fixed in trunk, which will become MacPorts 2.2.
>> 
>> I wanted to build the port and check `otool -L` under MacPorts trunk myself, but I cannot, because anjuta's dependency yelp does not build:
>> 
>> https://trac.macports.org/ticket/39536
> 
> 1) It's true that these are dependencies of subversion but I based the
> dependencies on what anjuta is looking for at configure time.  I don't
> think the otool trick is a valid way to establish dependencies because
> it often shows linkages that are passed on from a dependency not
> just those that are required to build.

That's the library overlinking phenomenon I was talking about, which will no longer happen under MacPorts 2.2, provided you rebuild all your ports with MacPorts 2.2.

> So I let the developers be my
> guide and list what they think the dependencies are.  Probably
> not a big deal one way or the other.

I got anjuta to build, and it does indeed independently link with apr, apr-util and neon, and I see their configure script specifically checks for them as well. I just wanted to bring it up because Subversion has for several years been working on switching from neon to serf, a move which has finally been accomplished in the just-released Subversion 1.8.0:

http://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted

So, any program linking with neon, on the assumption that that's what Subversion is using, will be wrong as soon as the subversion port is updated to 1.8. (I expect the maintainer will wait for 1.8.1, since 1.8.0 has a number of bugs.)