All of the failures seem to be expected integration spec changes 👍

@samdmarshall Thanks! Can you please add a CHANGELOG entry that describes it as succinctly as possible. Preferably a bit shorter than this blog post? ;)

However, before merging, I would like to see a test for the change and also the change with regards to locating a user’s Xcode project. I can do this or someone else can pick this up if I don’t get to it before then.

As i basically know absolutely no ruby at all you probably don't want me writing a test for this :)

This could use additional work, specifically the "SYMROOT" of the Pods.xcodeproj file should be set instead to "SRCROOT/RELATIVE_PATH_TO_USERS_XCODEPROJ_DIR/SYMROOT_FROM_USERS_XCODEPROJ".

@samdmarshall After thinking this over for a bit, I’m wondering about this part. Does this still work in the context of a workspace, or does one not use a workspace when using legacy build settings such as this?

The reason I’m asking is because in a workspace CocoaPods can support multiple user Xcode projects and I’m not sure what the SYMROOT would then be. Would it be a common dir?

That is where this gets tricky and up to the end user to a degree. What would happen then is that end user would have to decide on a common build directory or add in custom search paths themselves for the linkage to work correctly. At that point i'd deem it Someone Else's Problem™ -- meaning that the developer has to configure that themselves irrespective of this patch being in place.

Ok. In this case I think that we then should not try to automatically determine the path, as we cannot provide a full solution. Instead, what we can do is have a shortcut method which can be used to easily set the SYMROOT on all configurations from a user’s Podfile’s post_install hook and default it to the hardcoded version that you used in your current patch.

There needs to be a "default" solution in place based on a common case -- the Podfile being in the same directory as the user's xcodeproj. Keeping the existing SYMROOT default directory in the Pods.xcodeproj continues to ignore the problem and puts the burden onto the end user to specify a SYMROOT path that works for them. Setting a default for the known common case (mentioned) does no harm to anyone using non-Legacy settings and can only benefit everyone else. I see no reason to not have a way to configure this in the post_install hook, however this is not the place for this specific patch as it does nothing but shifts the burden of configuration further into the user's domain.

I am sorry to be such a stick-in-the-mud about this issue but this is one of the main pains i have with using cocoapods at all, since it literally will not work out of the box based on my Xcode settings. Settings which are still supported in the latest builds of Xcode. I don't think it is unreasonable to ask for this to exist as the default behavior as it mitigates an extra configuration step for some people and doesn't impact the majority of users in the first place.

This hasn't been touched in almost 3 weeks, if we are just waiting on the integration tests i can try to write them myself with some guidance.

@alloy ping on this one

Closed in favour of #3183.

Submitting fix to modify the Pods.xcodeproj PBXProject default build path ("SYMROOT") so that when dependencies get built to the correct locations in a standard configuration.

Background: By default Xcode configures itself to be set to creating unique build directories in the ~/Library/Developer/Xcode/DerivedData/ based on the project/workspace file. This setting can be changed by opening Xcode's Preferences > Locations, then clicking the button "Advanced..." listed under the "Derived Data" setting. Here one can set the default build location behavior for Xcode to use. When selecting "Legacy" this will have each project's targets get built to "SYMROOT", relative to the "SRCROOT" or "PROJECT_DIR" for that project.

Due to the default configuration for cocoapods, the Pods.xcodeproj file is stored in a subdirectory "Pods" that is (typically) listed along-side the user's Xcode project file and the newly created xcworkspace file. As a result, this means that all of the targets in Pods.xcodeproj will be built to a separate build folder and the aggregate target will have linker errors because it cannot find the library targets from Pods.xcodeproj.

Fix: To resolve this in the common case, setting the build path ("SYMROOT") of the Pods.xcodeproj to be set to "SRCROOT/../build" which will correctly deposit the built products from Pods.xcodeproj into the same build directory as the user's xcodeproj targets.

Notes: This setting doesn't impact any usage outside of the Legacy or Custom Project based build settings, where the build directory of the user's xcodeproj wouldn't be the same directory as the one used by Pods.xcodeproj.

This could use additional work, specifically the "SYMROOT" of the Pods.xcodeproj file should be set instead to "SRCROOT/RELATIVE_PATH_TO_USERS_XCODEPROJ_DIR/SYMROOT_FROM_USERS_XCODEPROJ". However resolving these paths correctly is far outside of my skill right now.

Existing users that use Custom or Legacy build locations in the common case (where the podfile is stored in the same directory as the user's xcodeproj file) will see an extra step removed. Users that store the podfile in a location that is not along-side their xcodeproj file will still have to manually adjust the build location paths as they have had to do so far.