How to get a full list of dependents?

Ian Wadham iandw.au at gmail.com
Sat Feb 9 22:43:49 PST 2013


On 10/02/2013, at 1:11 PM, Ian Wadham wrote:
> On 10/02/2013, at 7:37 AM, Joshua Root wrote:
>> MacPorts_Framework is still in a pretty "pre-alpha" state, so I wouldn't
>> worry too much about maintaining compatibility if not doing so will make
>> it better. Just make sure you mention the interface breakage in the
>> commit logs, and fix Pallet to match.
> 
> It looks as though backwards compatibility is an impossible ask in an Xcode
> environment.  For starters, there are all the .xcodeproj files.  My Xcode 4.6
> grumbles about them all the time and FAIK has already changed them a lot.
> The files in SVN are for Xcode 4.3, I think.
> 
> Then Xcode keeps "pushing" newer features that are somewhat
> fundamental, such as automatic reference counting and Interface
> Builder layouts with constraints.  These are nice features, but not
> backwards compatible.
> 
> Re the "pre-alpha" state of Macports_Framework, tell me about it … :-)
> 
> One problem is that there is almost zero error information (in an NSError
> object) passed back to Pallet, but lots of "comments to self" in the code
> about the need to do something.  Another problem is that Pallet ignores
> the NSError object anyway and treats all actions as successful.  A third
> is that actions like "install Growl" should always fail (the Growl port is
> broken), but sometimes are said to "succeed" (in the Console messages).
> 
> Macports_Framework has over 12,000 lines of code, and nearly 4,000
> lines are a copy of Apple code for BetterAuthorizationSampleLib, dated
> 2007 (Is that code still current, I wonder?).
> 
> Should I persevere with Macports_Framework?  It's been a while since I
> worked with threads and concurrent processes and Apple's way of doing
> things, in Objective C, OS X and Xcode is all new to me.  I enjoy a challenge,
> but in this case, is it (Macports_Framework) worth the effort?  People are
> lukewarm about having a GUI for Macports anyway.  I am not, but I find
> the framework for interacting with Macports to be huge and rather daunting.

I have copied this discussion to macports-dev, under a more relevant
subject line.  Please reply there.

Thanks, Ian W.


More information about the macports-users mailing list