Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Why is all Editor build-processing code gated to UNITY_EDITOR_OSX?

Đang mở
  • Có gì không ổn?
#125 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp, unity
Lĩnh vực
build-system, game-dev

Hướng nghiên cứu

Start with the UNITY_EDITOR_OSX guards in Apple.Core/Editor/AppleBuildProfile.cs, AppleBuildStep.cs, AppleBuild.cs, AppleCoreBuildStep.cs, AppleSecurityBuildStep.cs, and the other plug-in Editor files; compare them with Apple.BackgroundAssets/Editor/BuildStep.cs. Reproduce the Linux batchmode BuildPipeline.BuildPlayer compilation failure, then verify the agreed guard scope against the later macOS xcodebuild step; done means Linux export compiles and produces the Xcode project without breaking the macOS archive path.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Why is all Editor build-processing code gated to UNITY_EDITOR_OSX? (it blocks splitting the whole build to something like Unity export to happen on Linux machine and the Xcode build on macOS)

Context: the pipeline

Build split in two stages, on two different machines.

  1. Unity export, on a Linux machine — this is the step that opens the project in batchmode
    and calls BuildPipeline.BuildPlayer for iOS, producing the .xcodeproj.
  2. Xcode build, on a macOS machine — xcodebuild archive/export on the project produced
    in step 1.

This is a common CI shape for people that build for multiple platforms (iOS + Android, etc.) from
one Unity project and want to keep the compute-heavy Linux fleet doing as much of the shared work
as possible, only handing macOS machines the part that strictly needs Xcode.

What broke

Every Editor build-processing file I've looked at, across every plug-in in this repo, is wrapped
in the identical condition:

#if (UNITY_EDITOR_OSX && (UNITY_IOS || UNITY_TVOS || UNITY_STANDALONE_OSX || UNITY_VISIONOS))

UNITY_EDITOR_OSX is defined based on the OS the Editor process is running on, not the build
target. Since my export runs on Linux, this symbol is false there, for every file, in every
plug-in, simultaneously — this isn't per-file behavior, it's one symbol shared by the whole compile.

Two consequences I hit:

  • Apple.BackgroundAssets/Editor/BuildStep.cs is the one file in the whole repo missing this
    guard (every sibling file — AppleBuildProfile.cs, AppleBuildStep.cs, AppleBuild.cs,
    AppleCoreBuildStep.cs, AppleSecurityBuildStep.cs, AppleUserManagementBuildStep.cs, and the
    equivalent files in Accessibility, CoreHaptics, GameController, GameKit, StoreKit — all have it).
    Because AppleBuildProfile compiles out to nothing on Linux, but BuildStep.cs references it
    unconditionally, Editor script compilation hard-fails there:
    CS0246: The type or namespace name 'AppleBuildProfile' could not be found.

Why I don't think this needs to be macOS-only

I read through Apple.Core's Editor code specifically looking for something that would force it
to run on a macOS host, and didn't find one:

  • AppleBuildProfile (Apple.Core/Editor/AppleBuildProfile.cs) is a plain ScriptableObject:
    a dictionary, some strings, AssetDatabase calls. No OS-specific API anywhere in it.
  • AppleBuild.OnPostProcessBuild (Apple.Core/Editor/AppleBuild.cs) reads/writes Info.plist and
    entitlements files, opens the .pbxproj via PBXProject, and builds a shell-script string that
    gets written into a Run Script build phase. I grepped this file for Process.Start,
    ProcessStartInfo, DllImport, xcrun, codesign, lipo — anything that would mean this C#
    code itself invokes a native macOS tool during export — and found nothing. The only appearance
    of codesign in the file is as a literal string embedded in the generated build-phase script
    (around lines 398/409/455/466), meant to run later, under xcodebuild itself. That anyway
    must happen on a macOS machines regardless of this guard; it isn't a reason the export step
    needs to be on macOS too.
  • More generally: UnityEditor.iOS.Xcode (PBXProject, PlistDocument) is Unity's own managed,
    cross-platform library for editing .pbxproj/.plist files as structured text. Building an iOS
    Xcode project from a non-macOS Editor host and archiving it separately on macOS is a supported,
    fairly common CI pattern in the Unity ecosystem specifically because these APIs don't require
    Xcode or macOS to run — only the later xcodebuild step does.

Given all of that, I couldn't find a point in this code path where it actually needs the Editor
process itself to be on macOS, as opposed to needing a Mac only for the parts that were already
guaranteed to run there anyway (the later xcodebuild/archive step, and the earlier one-time
build.py step that produced the native libraries in the first place).

Where the guard came from

Introduced in commit b4002b66f01999e4b66f609974826aaf21d59eff ("Replacing Unity's native
library management", PR #27), which moved native-library selection/embedding from Unity's own
per-platform plugin importer into Apple.Core's own system.

Environment

  • Unity: 6000.4.0f1
  • Setup: Unity export on Linux, Xcode archive on macOS machines

Question

Is UNITY_EDITOR_OSX a hard technical requirement for this code, or a deliberate scope decision (i.e. "we only support this when the Editor host itself is macOS")? If it's the latter, would you consider narrowing the guard to only where it's actually load-bearing — e.g. around the native library embedding/signing calls specifically — so the rest of the Info.plist/entitlements/build-step machinery can run on a non-Mac Editor host, even if native library embedding itself still needs a Mac?

Ngôn ngữ chính
C#
Star
988
Fork
251
Merge trung bình
2 ngày 22 giờ
Pull request đã merge (30 ngày)
11

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apple/unityplugins

Tất cả issue của apple/unityplugins

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.