Changelog: Fix: [XcodeBuild] place all intermediate build files in the cache build folder
Changelog: Feature: [XcodeBuild] allow passing build configuration and arbitrary command line params
Docs: conan-io/docs#4171

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

Build configuration

Xcode projects come with 2 build configurations by default: Debug and Release. In my recipe I pass the following property as configuration param:

@property
def _buildConfig(self) -> str:
    return self.settings.build_type if self.settings.build_type == "Debug" else "Release"

Maybe this logic should even be moved to Conan?

Arbitrary xcodebuild params

For example, in my recipe I pass the following xcodebuild variables:

• BUILD_LIBRARY_FOR_DISTRIBUTION=YES - plays an important role in building Swift code as it enables "library evolution" which allows consuming prebuilt binary/module by a later Swift compiler version
• MACH_O_TYPE=mh_dylib (and EXECUTABLE_EXTENSION=dylib) to make a static library/framework target produce a shared library. The same variables with respective values could be used the other way around - to produce static library from a shared library/framework.
• RUN_CLANG_STATIC_ANALYZER=NO to disable static analyzer launch (when a project enables it) that is useless for Conan build where I simply want to obtain a binary

A couple of other commonly used xcodebuild params would be -workspace to use .xcworkspace instead of .xcodeproj and -destination to select target device.

Redirecting build artifacts to the cache build folder via SYMROOT+OBJROOT variables

Activated via constructor parameter, off by default for backward compatibility.

Will copy my arguments in favor of this change from #18496

it solves 2 things:

1. by default, SYMROOT is set to build directory inside the source directory and OBJROOT has the same value as SYMROOT. But projects can override any of those settings in the Xcode project file and you'll never know where the build files are. Since Conan has a dedicated build directory, it's better to keep build artifacts in there. Having build files in the source directory looks even worse to me when no_copy_source is True.

2. it makes it easy to access build artifacts, here's an example from my recipe:

@property
def _buildConfig(self) -> str:
    return self.settings.build_type if self.settings.build_type == "Debug" else "Release"

def package(self):
    artifactsDir = os.path.join(self.build_folder, f"{self._buildConfig}-{self.settings.os.sdk}")

and now you simply copy .framework / .dylib / .a from the artifactsDir

changing some command layout things with SYMROOT, OBJROOT. These seems should be defined at the project level, or in any case at the toolchain level. Because otherwise, normal flow like conan install + IDE/xcodebuild direct user invocation will do something different

I can't really agree with this.

1. When building from Xcode IDE, those variables are ignored by default and Xcode places all the stuff in ~/Library/Developer/Xcode/DerivedData/<dir>. They will be used only when project is configured in such a way, but AFAIK it's rarely done nowadays. This is configured in File - Project settings... - Advanced - set to Legacy. This behavior was changed to Legacy like 10 years ago or even more.

2. Suppose we don't touch those settings. How can a recipe figure out where the build artifacts are? The only reliable way would be to invoke xcodebuild -showBuildSettings to see the actual value of all settings and grep SYMROOT. Do you really expect every recipe to include such a piece of code (or have a Conan helper function)? To me it looks like an unnecessary complication when you can set a reliable path at build time. And also polluting source directory by default which we have already discussed. And one more point here: as soon as I have redirected SYMROOT+OBJROOT, tests started failing because they rely on hardcoded default value, see 2da70f5