boost port file does not properly include isysroot

[Ryan Schmidt]

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

> On Jan 28, 2012, at 3:43 AM, Ryan Schmidt wrote:
> 
>> On Jan 27, 2012, at 19:38, James Gregurich wrote:
>> 
>>> I have macosx_deployment_target set to 10.6. The boost port file does not add in the sdkroot as it should. TO fix, modify the last line in the post-configure function to add in the isysroot entry...
>>> 
>>> 
>>> fixed line:
>>> 
>>> write_jam "using darwin : : ${filter}${configure.cxx} -isysroot ${configure.sdkroot} ;"
>> 
>> Feel free to file an enhancement request about this in the issue tracker. I predict you'll run into similar problems in many, many other ports, since cross-compiling for another SDK is not something most users or maintainers ever test.
> 

> then people must not be using macports for commercial development because there is no way commercial developers can drop 10.6 support yet.
> 
> given the time I have wasted trying to contribute to this project, I'm not inclined to spend any more time figure out how to file bug reports on it. I've made the problems known to you guys. handle them as you wish. I'm resigned to eventually going back to manually building my libs as I don't see this project as having a significant future.


Thank you for bringing the problem to our attention. I've filed a bug report about it:

https://trac.macports.org/ticket/33085

As I said, what you're doing with MacPorts is uncommon; most users just use MacPorts to install software they want to use themselves on their own computer.

So you might run into this problem with other ports as well. You can file tickets about them as well, and especially if you can figure out how to fix them, that will make it more likely we'll fix the ports.

Here are the bug reporting instructions, for your future reference:

http://guide.macports.org/chunked/project.html

For the record, you can definitely use MacPorts to build software that works on 10.6 -- by running MacPorts on 10.6, not 10.7. It's cross-compiling for a different SDK that's an unusual use for MacPorts. But since we do expose the option to change the SDK in macports.conf, we should strive to fix any problems that arise because of this.