Support External Target Reference

[kateinoigakukun]

Motivation

XcodeGen supports generating schemes but it only allows to reference it's own targets in project.yml.
We often want to execute unit tests over xcodeprojs at once.

Changed

This pr added externalProject property which enables to build other project targets.

And added new syntax to reference other project target.

projectReferences:
  FooLib:
    path: path/to/FooLib.xcodeproj
schemes:
  TestTarget:
    build:
      targets:
        FooLib/Target7: ["run"]

[yonaskolb]

I'd like to move towards being able to reference other projects in more places in an easy way. This might be a good place to start to doing that. I think target: String could be turned into target: TargetReference

struct TargetReference {
  let name: String
  enum Location {
  	case local // better name? spec?
  	case project(path: String)
  }

  init(string: String) {
	..
  }	
}

(In the future this could include a case for named projects when the spec supports multiple projects.) We just need some syntax to describe it in a string so it can be defined and parsed. Something like MyProject.xcodeproj/target

[kateinoigakukun]

@yonaskolb I implemented ProjectName/TargetName syntax to represent other project target.

What do you think about this syntax?

externalProjects:
  FooLib:
    path: Libraries/FooLib.xcodeproj
schemes:
  TestTarget:
    build:
      targets:
        FooLib/Target7: ["run"]

[kateinoigakukun]

@yonaskolb Sorry for pinging you, cloud you review again?

[giginet]

Excellent features! We can't wait to use them.

I noted trivial points.

[giginet]

Is this true?

Can you try project.basepath to get xcodeproj path.

[kateinoigakukun]

Yes, ReferencedContainer is relative to a directory which has xcodeproj

[yonaskolb]

While there's nothing bad with having specific errors thrown here, checks like this occur in the SpecValidation phase. Adding a new set of SchemeGenerationErrors just introduces more maintenance. The rest of the codebase gracefully fails at points like this. Thoughts @kateinoigakukun, @giginet?

[giginet]

You're right this condition will be not caused by user inputs, seems to be caused by an implementation error.
Other exceptions will be occurred by user inputs, however, here is not.
It's better to call fatalError instead of throwing the exceptions here.

[yonaskolb]

Sorry @kateinoigakukun, could you revert to how you had it before then

[yonaskolb]

This could become a performance issue, especially if there are lots of target references. We could at least cache the projects in this class

var projects: [String: XcodeProj]

As far as I understand you're only loading these projects to get the proper file extension for the target right? Does the buildable name require that? Cause if it doesn't we can just do away with loading the projects.

[kateinoigakukun]

We could at least cache the projects in this class

Right, I added cache logic.

As far as I understand you're only loading these projects to get the proper file extension for the target right? Does the buildable name require that? Cause if it doesn't we can just do away with loading the projects.

PBXProj is also used to get blueprint of target https://github.com/yonaskolb/XcodeGen/pull/655/files#diff-b0109f56886f826d76bacb6b15dbf86dR132

[yonaskolb]

Awesome, nice work @kateinoigakukun!