I’m seeing an issue with CMake 3.17 (doesn’t seem to occur with CMake 3.16.5) where the generated command line includes two different macOS SDK locations. The actual active SDK (based on XCode-select) is included via -isystem, but the ‘command line tools’ SDK is also included via -I and this caused many compile failures.
Sample make line shown below, also occurs with Ninja:
Can you provide a minimal project which reproduces the problem for you? I just happen to be looking at Apple/Xcode things this evening, so if you can provide a simple reproducer, I may be able to take a quick look later on.
Ah bad (good?) news, I just downgraded to Cmake 3.16.5 on the problem machine and the issue still occurs. But on another machine with Cmake 3.16.5, things work as normal. So now I’m suspecting the recent XCode 11 broke this, except in principle that update is also on both machines.
The project I’m testing with is a helper library called Simgear, it’s on SourceForge here. You can configure it with ‘-DSIMGEAR_HEADLESS=1’ to have it build with no additional dependencies on macOS. I can try to make an actual minimal test case but it will take longer of course.
One additional data point - I did just reset my active SDK (using xcode-select -r) and then reselect the ‘right one’ (/Applications/XCode.app/Contents/Developer) but this didn’t help at all.
I just made a very minimal test project, and it does /not/ exhibit the problem. So it’s something in the project configuration, causing the additional SDK path to be added.
Another thing for you to check is whether there are signing identities available on the machines involved.
The process of producing a minimal project often uncovers the underlying issue on its own, so I encourage you to do that (it will also help you focus on the problem rather than getting lost/masked by things the real project might be doing).
You can also specify which Xcode to use when invoking cmake by setting the DEVELOPER_DIR environment variable. For example, I’m doing a lot of the following tonight to investigate signing issues:
Okay one difference between the machines: the ‘working’ machine does not have an SDK (or anything, really) in /Library/Developer/CommandLineTools. This suggests a work-around might be to nuke the CommandLineTools SDK.
I’m going to try to cut down the real project incrementally to see what feature/test is introducing the weird -I include - unfortunately it’s a remote build machine so rather slow to test on.
Okay, it’s find(CURL) which is causing the extra -I path to be added, about to dig and investigate why : and I’ll that to my minimal project to confirm.
What’s happening is that FindCURL.cmake is finding curl.h in the Developer/CommandLineTools SDK. This is then added to my target via CURL_INCLUDE_DIR and . Of course it will only occur if that location contains a valid SDK.
What I don’t know is how find_path() interacts with the rest of CMake, to find the SDK, respect the value if -isystem and so on. (Well, clearly it’s not respecting the value that will be passed via -isystem…)
I tried your project on my machine, which does have /Library/Developer/CommandLineTools. It works for me, but I do not see /Library/Developer/CommandLineTools in the compiler command lines. I’m using CMake 3.17.1 and Xcode 11.1. I also checked the CMakeCache.txt file and it is finding curl.h from Xcode’s SDK, not from the command line tools area.
Okay, since I have a work-around, I guess we can ignore this for now. I don’t understand why find_path would work so differently, but it must be something in the machine setup. And hopefully if this happens for someone else on another project they will find this.
