Fixes problems loading information about workspaces

[jamiely]

There are problems that occur because xcodebuild -list -workspace FILE only returns scheme information

[codecaffeine]

@jamiely I’ve run into this problem as well, but this solution might be problematic.

Assume you have both a FooBar.xcodeproj and a FooBar.xcworkspace file in the directory you’re running this from (very common use case, especially with CocoaPods). When you run xcodebuild -list without the workspace argument, it pulls from the FooBar.xcodeproj rather than the FooBar.xcworkspace which may have different targets, schemes, and configurations defined.

The ultimate issue is @xcodebuild_info.build_configurations will be nil if a workspace is passed in. This causes a crash because build.rb has a check to make sure the selected build_configuration is in @xcodebuild_info.build_configurations.

The best solution is to not check that the configuration isn’t in the list of available configurations. This check isn’t needed because xcodebuild will use the default configuration if it doesn’t recognize the configuration that’s passed in.

[mattt]

Sorry to be late to the party. What's the consensus on this, @jamiely & @codecaffeine? Should this patch be merged, or is there another fix to use?

[jamiely]

@codecaffeine has a good point. I think that should resolve the issue.

[codecaffeine]

Unfortunately, xcodebuild -workspace <workspace> -list just doesn’t give as much info as xcodebuild -project <project> -list. I’m guessing this is because workspaces only deal with schemes which tie the configuration to the build action?

The other option I’ve played around with is parsing the workspace file (contents.xcworkspacedata) to get the project file paths and passing that into xcodebuild. It didn’t really give me any added benefits and made the code more fragile (parsing XML, handling multiple project files).

[lukeredpath]

Running into this problem too; ultimately, I think if a workspace and scheme are specified, then configurations are completely irrelevant as they are specified by the scheme. I think shenzhen is trying to be too clever for its own good and is essentially trying to duplicate the logic of what combinations of project/workspace/scheme/configuration are valid - it should just past options into xcodebuild and let xcodebuild fail if the wrong options are supplied IMO.

[lukeredpath]

Its worth pointing out that this was already fixed once in #13

[codecaffeine]

I agree with @lukeredpath because xcodebuild always uses default configuration even if nothing is passed using the -configuration flag. The -configuration flag is just an override from the default behavior. Therefore, I’d go as far as to remove the determine_configuration! method.

[codecaffeine]

The downside with the above change is we lose the configuration reference in Build Output Info:

Building "MyApp" with Scheme "MyScheme" and Configuration "Debug"

becomes

Building "MyApp" with Scheme "MyScheme"

[codecaffeine]

Hrmm. Just running shenzhen with ba9ec07, I really dislike not knowing what the configuration is. Any other thoughts?

[lukeredpath]

Maybe saying something like "using default configuration [for scheme]" would be reassuring?

On 21 May 2013, at 16:02, Matt Thomas notifications@github.com wrote:

Hrmm. Just running shenzhen with ba9ec07, I really dislike not knowing what the configuration is. Any other thoughts?

—
Reply to this email directly or view it on GitHub.

[lukeredpath]

Does 'xcodebuild [opts] -showBuildSettings' provide anything more useful?

Sent from my iPhone

On 21 May 2013, at 16:02, Matt Thomas notifications@github.com wrote:

Hrmm. Just running shenzhen with ba9ec07, I really dislike not knowing what the configuration is. Any other thoughts?

—
Reply to this email directly or view it on GitHub.

[codecaffeine]

It -showBuildSettings does show the default configuration.

There is a quirk, though. If you have a unit testing target tied to the scheme, it’ll show the build setting for both the app target and the unit testing target.

[codecaffeine]

In 260d804, I’m gathering the build settings before we set the configuration variable. That way we can set it to the build setting CONFIGURATION if it’s not specified as an argument.

xcodebuild is interesting. If you pass a -target the default configuration is Release but if you pass -scheme the default configuration is Debug. The more you know 🌠

[codecaffeine]

FYI, 260d804 has a bug with PackageApplication if you override the default configuration. I’m still investigating

[mattt]

@codecaffeine Alright. Keep me posted, and let me know when the pull request is ready to be merged in.

[codecaffeine]

@mattt I’ve been running with this change for the past week without issue. I do wonder if there’s a good way to add some sort of testing to Shenzhen.

[mattt]

Really sorry for how long this took to merge in, @codecaffeine. 6208ad8 is finally in master. Cutting a new release as soon as I clear out the rest of the open issues. Thanks!

[codecaffeine]

Hah, no worries! You have a lot going on. asciiwwdc.com alone is worth the wait