Adding default build configuration for scheme in XCode

For now, the default build configuration in the XCode scheme is hardcoded in cmXCodeScheme.cxx. For example, the build configuration for launch action(the “RUN” command in XCode) is “Debug”.

Sometimes, it’s not what the users wanted. For the project that I’m working on, I want the default build configuration for “RUN” is “RelWithDebInfo”. Since our project is a huge one, sometimes it took a long time for me to build then realized that I did not choose the right build configuration.

I think we can add a new XCODE_SCHEME_DEFAULT_RUN_CONFIG property for users to set the default build configuration to what they want. I have created a branch to do some tests and it’s working well for me. If this is a meaningful addition to CMake, I would be more than happy to submit a merge request.

1 Like

The feature seems reasonable to me.

Cc: @gjasny @brad.king

The CMAKE_DEFAULT_BUILD_TYPE variable added in CMake 3.17 is somewhat related. It is only for the Ninja Multi-config generator at the moment though.

Are there any updates to this? Or any workarounds to try? Thanks so much :slight_smile:

I’m not aware of anyone working on changes related to this topic.

Hi, sorry for not following this. After I post this, our team made a decision and switched to another build system. But I have a working draft. The code is actually very simple.

I added a new XCODE_SCHEME_DEFAULT_RUN_CONFIG and in Source/cmXCodeScheme.cxx, instead of WriteLaunchAction(xout, FindConfiguration("Debug"), container); I use:

std::string launchConfiguration = this->Target->GetTarget()->GetSafeProperty(
   "XCODE_SCHEME_DEFAULT_RUN_CONFIG");
 if (launchConfiguration.empty())
 {
   launchConfiguration = "Debug";
 }
 WriteLaunchAction(xout, FindConfiguration(launchConfiguration), container);

You can give it a try.

1 Like

An MR with these changes (and doc additions) would be greatly appreciated :slight_smile: .

Rather than adding a new property or variable, I do think it would be better to use the existing CMAKE_DEFAULT_BUILD_TYPE variable for this. If that variable isn’t set, we could use the first config listed in CMAKE_CONFIGURATION_TYPES as a fallback. I think that would still give us the same behavior as now if CMAKE_DEFAULT_BUILD_TYPE isn’t set and CMAKE_CONFIGURATION_TYPES is left at its default value. We should avoid adding a new Xcode-specific variable when a more general, suitable variable already exists.

CC: @kyle.edwards for awareness (proposing to expand the generators that CMAKE_DEFAULT_BUILD_TYPE applies to).