Installations without Command Line Tools

Ryan Schmidt ryandesign at
Mon Sep 24 19:27:18 UTC 2018

On Sep 24, 2018, at 11:06, Frank Schima wrote:

> On Sep 24, 2018, at 1:48 AM, Joshua Root wrote:
>> Currently, portconfigure::configure_get_sdkroot will return an error if
>> there is no SDK for the current OS version, and /usr/include also is not
>> present [1]. A recent change stopped warning about the lack of
>> /usr/include when using recent Xcode versions [2].
>> This leaves us in a situation where a user who installs Xcode and
>> MacPorts but not the Command Line Tools will see errors, with no hint as
>> to how to resolve them. The three obvious ways forward would be:
>> 1. Go back to recommending having the Command Line Tools installed,
>> warning if they are not present.
>> 2. Uncomment the code at the end of configure_get_sdkroot that would
>> fall back to using the "macosx" SDK link if the specific version
>> requested is not found. This has risks that are explained in the comments.
>> 3. Recommend that users install the SDK for their OS version when Xcode
>> does not include it. This could involve adding a link in the error
>> message to a wiki page with download and installation instructions.

I believe my MacOSX.sdk port suggestion will implement solution 3.

>> - Josh
>> [1]
>> <>
>> [2]
>> <>
> Option 1 makes sense to me. However, it sure would be annoying to those people who do not intend to install the CLT.

Note that as of 10.14 /usr/include appears to be deprecated. Unlike on 10.13 or earlier, the command line tools for 10.14 do not install /usr/include. For users who absolutely need /usr/include, the command line tools for 10.14 install the package /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg; users can install that package to install /usr/include. But this is clearly meant to be a stopgap measure and we should strive to make MacPorts work without that, if it doesn't already. (We previously said that MacPorts 2.5.0 made it work without the CLT but I have not checked.)

> So maybe add a macports.conf parameter to allow disabling the warning for people who know what they are doing?

I wouldn't favor that. If the warning makes sense, we should warn. If it doesn't, we shouldn't.

More information about the macports-dev mailing list