Xcodebuild fails when building Package.swift in the presence of a top level .xcodeproj or .xcworkspace file

[shahzadmajeed]

When you build/test a Swift package in a directory where both Package.swift and *.xcodeproj exist at the top level, xcodebuild fails to recognize a scheme "MyPackage-Package" in the Swift package (.swiftpm).

It is most probably because the presence of .xcodeproj forces xcodebuild to use that project by default, even if you are not specifying -project or -workspace argument when building the Swift package.

There should be a way to specify user intentions via. xcodebuild arguments so that the build system knows exactly what to build/test.

[NishanthMolleti]

Hi, I'd like to work on this. Here's my plan:

Root cause investigation:

• Identify where in swift-llbuild (or its integration layer with xcodebuild/SPM) the project-vs-package priority decision is made — specifically which code path causes
  .xcodeproj presence to shadow Package.swift when no explicit -project or -workspace flag is passed.
• Determine whether the fix belongs in llbuild itself or in the SPM build manifest generation layer that feeds llbuild.

Proposed fix:

• Add a mechanism (e.g., a --package flag or equivalent) to xcodebuild's llbuild integration that explicitly signals "build the Swift package, not the Xcode project" when
  both coexist in the same directory.
• Alternatively, invert the priority so Package.swift takes precedence over .xcodeproj when no explicit project/workspace argument is provided — matching the user's
  mental model of a "Swift package repo that also has a legacy xcodeproj".

Deliverable: A PR with the fix + a test case covering the mixed Package.swift + .xcodeproj directory scenario.

---

One caveat to mention: the priority logic may actually live in xcodebuild itself rather than in swift-llbuild. Worth flagging this to the maintainer so they can either
confirm scope or redirect you to the right repo before you start digging.