boost port file does not properly include isysroot

[Ryan Schmidt]

On Jan 30, 2012, at 16:30, James Gregurich wrote:

> As you will recall from a year ago, I've already done that.
> 
> I gave you guys a complete working prototype that had support for clang, customization of  universal binary architectures, and the comprehensive ability to target different SDKs. I had 5 or 6 ports (including complex ones such as boost) building simultaneously for MacOSX and iOS as universal binaries on both. 
> 
> only one person ever cared enough to look at it.
> 
> 
> So, you are giving this lecture to the wrong guy. I voluntarily donated multiple weeks of expensive engineering time to macports to make it suitable for commercial developers on MacOSX and iOS.   I got NOTHING for that work….not even a "thanks for your efforts, but we really aren't interested."
> 
> 
> The time I spent learning and modifying the internals of mac ports showed me that there was no TECHNICAL reason why macports couldn't support the necessary options to handle commercial development. In fact, most of the work was already done…it was just incomplete. The reasons why the work is incomplete has to do with the attitudes and interests of the maintainers.  that's fine. You guys have every right to be disinterested in commercial developers if you choose.  But, I will say this…the majority of the developer action on Apple platforms is in commercial development….not unix nerds tinkering with KDE builds or server farm maintainers with fixed installations that rarely change. So, if you want your work actually used en masse, then perhaps commercial developers should be a more important audience.
> 
> 
> As for me personally, after I have seen that you guys simply aren't interested in commercial development, I'm making my plans to ditch mac ports in my work flow at some convenient time. I've been doing what I can to lobby Apple to create an official, properly maintained ports collection. I have no idea if Apple has any interest in that, but it doesn't hurt to ask.
> 
> 
> Finally, I didn't write in to "complain." I wrote in AS A COURTESY to tell you that the next Xcode beta breaks some of your code and tell you exactly what needed to be fixed. If you don't care, that's fine with me. I can hack my personal install to make it work for me in the short term to get what I need done for now. At least I can get some good out of all that time I spent working on macports.

I can tell that you're frustrated, and I apologize that we weren't able to accommodate you or meet your expectations. I don't think any of us have any objection to commercial software development particularly, it's just that that's not what the majority of users who write on our mailing lists are doing; they're installing software for their own personal use. So modifications that aren't needed for that use case might be ignored by those who don't need it. Please remember that MacPorts is free, and that most of us are here in our free time, working on MacPorts because we enjoy it, but this also means that a lot of stuff probably doesn't get done that would be nice to have. We don't have a roadmap or to-do list; we work on whatever interests us at the moment.

For the record, MacPorts was started by Apple; is hosted by Mac OS Forge, which is owned by Apple; and there are a number of MacPorts contributors who work at Apple. So if there is any Apple-blessed ports collection, my opinion is that MacPorts is it. If Apple felt that MacPorts was not being properly maintained or not meeting the expected needs, and Apple had an interest in improving the situation, they could certainly hire more developers to participate here. Of course, that goes for anyone: as you said developer time is expensive, but if your company felt MacPorts was important and wanted to pay you to work with us to improve it, they could do that.

I do remember your iOS/cross-compiling submissions now. I apologize that I was not able to review them. As I recall, you only provided links to archives on your Mobile Me web space, and by the time I got around to reading your emails, the files were no longer there. Change requests should usually be submitted as tickets in the issue tracker, with an attached diff, that way they won't get lost. Smaller more focused diffs are easier to review and thus more likely to get accepted than huge diffs that change things all over the code base.