Xcode using an inconsistent version of make

Hello!

I'm new to Xcode and Apple development in general. I'm trying to set up Xcode to work with an existing C++ project that uses Makefiles. I'm using Xcode 14.2. I have the project set up as an "External Build System" project with the "Directory" setting pointing at the root of my project's source (where the Makefile is located), and the "Build Tool" set to /usr/bin/make (the default).

When I do Product -> Build, the project builds fine. However, when I view the build log I see that it is invoking /Applications/Xcode.app/Contents/Developer/usr/bin/make instead of /usr/bin/make.

The two files are not the same. The /usr/bin/make file has a size of 167136 bytes. The /Applications/Xcode.app/Contents/Developer/usr/bin/make file has a size of 436512. So, it appears that Xcode is using the 'make' that is part of its own installation and not the 'make' that is explicitly specified as part of the "External Build System" configuration. Is this normal behavior? It seems rather odd to me.

I also notice inconsistencies. If I try to use /usr/bin/make directly (for example, in a separate terminal), after I've done a build via Xcode, I tend to get errors like this: "warning: object file (clac.o) was built for newer macOS version (13.1) than being linked (13.0)" I don't fully understand what this is telling me, but I feel like it's related to the inconsistency I described above.

Thanks for any help, advice, or thoughts you might have!

/usr/bin/make is a shim, it will use the make version of the currently selected Xcode toolchain (see xcode-select command or Xcode preferences). The second issue is caused by minimum deployment target not being set. See https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html

Thanks for your reply, it was helpful... although I am still a little stuck.

First, the document you linked talks about a /Developer folder, which doesn't exist on my system (I'm running macOS 13.1 with Xcode 14.2). However, there is a folder named /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer which I suspect is what the documentation is talking about because it contains an SDKs subfolder as mentioned by the documentation. There I see symbolic links named MacOSX13.1.sdk and MacOSX13.sdk that both point to the folder MacOSX.sdk. So that makes sense.

However, following the directions in the documentation, I tried to set MACOSX_DEPLOYMENT_TARGET to 13.0 and SDKROOT to 13.1. I understand this to mean that the program may not load on any version of macOS less than 13.0, and that I would need to dynamically test for the presence of 13.1-specific APIs before I can use them. In actual fact, I don't need to do anything with 13.1-specific APIs (right now, anyway!), but I just wanted to see how it worked.

When I say "I tried to set..." I mean that I modified the "Build Settings" for my external target in Xcode by adding two new user-defined settings for MACOSX_DEPLOYMENT_TARGET and SDKROOT.

Unfortunately, when I tried to build, it failed immediately with the error "unable to find sdk '13.1'". I tried setting SDKROOT to 13.0 (since it didn't seem to complain about my use of 13.0 in MACOSX_DEPLOYMENT_TARGET), but then I got "unable to find sdk '13.0'". For good measure I also tried changing the setting to just 13, but that produced the same error message. I next tried to just remove the SKDROOT setting entirely, but I can't figure out how to do that! There is a "+" button for adding settings, but no "-" button for removing them. Just erasing the setting didn't work. I got "name cannot be empty."

This all comes down to two questions:

  1. Why can't it find the SDKs? They appear to exist on my system.
  2. How does one remove a user-defined build setting in Xcode?

Thanks!

I have a similar problem of not finding MacOSX13.1.sdk when building a kernel on MacOS12.6.4. I see these files in .../Platforms/MacOSX.platform/Developer/SDKs:

drwxr-xr-x 7 root wheel 224 Nov 12 13:18 MacOSX.sdk lrwxr-xr-x 1 root wheel 10 Mar 10 09:26 MacOSX13.1.sdk -> MacOSX.sdk lrwxr-xr-x 1 root wheel 10 Mar 10 09:26 MacOSX13.sdk -> MacOSX.sdk

So one reason for failure might be over-zealous search for a directory only, and not allowing symbolic links.

Xcode using an inconsistent version of make
 
 
Q