On Jan 27, 2012, at 5:32 PM, James Gregurich wrote:
>
> expat.
>
>
> I'm developing on 10.7 against the 10.6 sdk.
>
>
> On Jan 27, 2012, at 5:03 PM, James Berry wrote:
>
>> James,
>>
>> I've check into svn a fix for the first problem. We now use xcrun to find
>> the compiler tools, and so can find the compilers okay.
>>
>> I hadn't encountered the other issue, likely because I haven't been building
>> any macports app that use the sdk.
>>
>> I'll see if I can take a look at the other issue (sdkroot) as well. Is there
>> a particular port you saw this issue with?
I looked a bit into the issue of the sdkroot. I'm not inclined to work on it
any more, as it's not something I have time for, nor particular interest in, at
the moment. But I thought I'd take a moment to give some ideas for anybody who
might want to look into it:
(1) Xcode keeps moving this stuff around, and is now moving it yet again, and
into the Xcode app directory. The fact that we're having to add lots of special
cases likely indicates we're going about things in the wrong way. We might want
to consider a change of approach for this setting.
(2) That said, one possibility would be to just add some new checks and
special cases, figure out where the user has their Xcode app (either by looking
in the application directory in system and user domains, or perhaps by using
the mdfind tool), and perpetuate the madness with new special cases and checks
to find the SDKs therein. This likely, would be the easiest thing to do, at
least in the short term.
(3) With my recent changes to finding compilers, we now use xcrun to find a
compiler, but not to invoke it. One possible change that could help this issue
of the sdk setting would be to use the xcrun to actually invoke the compiler,
passing the -sdk option to it (this option takes the sdk name, rather than the
full path, letting it use its knowledge of the Xcode and sdk locations to form
the ultimate path). But this option wouldn't help at all for invoking non-xcode
compiler versions.
(4) I played around with various ideas for getting the Xcode tools xcrun or
xcodebuild to actually spit out the needed sdk path. One thing that would I
think work would be to build, and include with MacPorts, a simple xcode project
that contained a script phase that would print out needed paths. This project
could be invoked with xcodebuild, passing it the needed -sdk name, and the
output from the script phase parsed to garner any needed paths for isysroot,
and even for Xcode itself if needed.
Hopefully somebody with time and/or inclination can implement one of these
options, or one of their own ;)
James
>>
>> James
>>
>> On Jan 27, 2012, at 3:18 PM, James Gregurich wrote:
>>
>>> I'm not sure if this is known or not, but Xcode 4.3 breaks macports. I'll
>>> report what I have learned in hacking my macports install into working.
>>> Note that /Developer has been moved inside the Xcode.app package and the
>>> internal structure of Developer has changed.
>>>
>>>
>>> In xcode 4.3, "/Applications/Xcode.app/Contents/Developer/usr/bin" does
>>> not contain clang and clang++.
>>>
>>>
>>> Also, the sdkroot calculation is also now wrong as the macosx sdk is now in
>>> the platforms folder. To illustrate, the path to the 10.6 sdk is now:
>>>
>>>
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk
>>>
>>>
>>> Here is the line I corrected to make the change in portconfigure….although
>>> I'm sure you'll need more logic to make this change only for Xcode 4.3.
>>>
>>>
>>> set sdk
>>> "${developer_dir}/Platforms/MacOSX.platform/Developer/SDKs/MacOSX${macosx_deployment_target}.sdk"
>>>
>>>
>>>
>>> -James
>>>
>>>
>>>
>>> _______________________________________________
>>> macports-dev mailing list
>>> [email protected]
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>>
>
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
