More Xcode version confusion

See among other things, this post.

After quite a bit of working around issues, I got my project setup correctly using tuist while Xcode 11.5 was selected (so tuist would work). I then decided to run “tuist up”.

It worked just fine in that it built all the carthage dependencies I had listed. What I did not realize is they were built using my selected Xcode, and thus using the latest swift compiler available there. Since the rest of my app requires Swift 4.2 problems ensue.

It would be great if, for the tuist up one could specify the desired Xcode version. The command would use Xcode-select to discover the current setting, use it also to change to the desired version, do the “up” work, and then change it back.

I realize that:

  • This could cause conflicts elsewhere on the computer if it is using Xcode or Xcode tools, but it would be acceptable to me
  • I can run carthage manually to get around this
  • it would be even nicer if, somehow the version of the swift compiler could be controlled.
  • There may be a way by manipulating environment variables before forking carthage…

@dolfs I wonder if it’d make sense to add support for automatically selecting versions of Xcode when cd’ing into directories that contain Tuist projects? For example, if you cd into a directory with a Setup.swift that indicates that you should use Xcode 11.5, we could call xcode-select for you and make sure that the right version is selected.

Perhaps I misunderstand, but generally you would not be able to intercept cd commands, although aliases could be used to fire up some Tuist command during it. However, I do not think this is what is desired anyway.

The automatic selection, certainly as implemented right now, requires execution of Xcode-select and capturing its output (as in XcodeController). Doing this a lot would be quite a bit of overhead. If the automatic selection only happens “inside” of Tuist commands, just before they are going to have to rely on xcodebuild and similar, it minimizes overhead and would achieve some solution to what I described. It would be important though, that when automatically switched, it would also be switched back, so as to avoid user confusion.

On the other hand, an automatic switch that couldn’t be circumvented might cause problems too. Right now, for example I am manually switching with Xcode-select and by running the desired Xcode app (which might not be the selected one), to get a single project to work with Tuist and still operate correctly using Xcode 10.1 and 11.5. This requires selecting 11.5 while doing Tuist stuff, and selecting 10.1 when everything has been generated, so I can go build the project using 10.1.

I would suggest that the Setup.swift file could have its functionality expanded to allow for additional behavioral control of Tuist (such as a “automatically switch Xcode yes/no”) control. If this is combined with my suggestion to “search upward for Setup.swift” (made here) it becomes a useful mechanism for controlling Tuist behavior. It would certainly be compatible with the desire to control everything from Swift. It may be, though, that a minimal shell of Tuist functionality cannot depend on swift if you want to allow various switching behaviors etc. In that case .tuist file in directories might be an alternative.