Search Unity

  1. Full schedule for #UniteBerlin is now available! Featuring talks on our roadmap, hands-on labs and much more! Check it out!
    Dismiss Notice
  2. Unity 2018.1 has arrived! Read about it here
    Dismiss Notice
  3. Scriptable Render Pipeline improvements, Texture Mipmap Streaming, and more! Check out what we have in store for you in the 2018.2 Beta.
    Dismiss Notice
  4. ARCore is out of developer preview! Read about it here.
    Dismiss Notice
  5. Magic Leap’s Lumin SDK Technical Preview for Unity lets you get started creating content for Magic Leap One™. Find more information on our blog!
    Dismiss Notice
  6. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

BuildTargetGroup, BuildTarget: the difference between the two

Discussion in 'Documentation' started by rcenzo, May 30, 2017.

  1. rcenzo


    Aug 21, 2014
    In multiple entries in the documentation, use of the enumerations BuildTargetGroup and BuildTarget is confusing as both seem to be very similar. In methods like EditorUserBuildSettings.SwitchActiveBuildTarget(buildTargetGroup, buildTarget), or even BuildPipeline.BuildPlayer, the two are often merely described as "the build target" or "the build target group", without actually explaining what the two individually mean.

    To my understanding, the BuildTargetGroup is used as the target you switch to in build settings, like PC/Mac/Linux (BuildTargetGroup.Standalone), and the BuildTarget the actual executable package which you'd build to using Ctrl/Cmd-B. However, this is not accurately described anywhere in the docs. Also, Unity expects to get two similar enums, like BuildTargetGroup.Android and BuildTarget.Android, but this does not restrict the developer to mix them up: which led to very odd results, debunking my theory.

    For instance, I wanted to see the results (5.6.1f1, Win64) when executing this method, knowing that Unity would probably dislike it:
    EditorUserBuildSettings.SwitchActiveBuildTarget(BuildTargetGroup.Android, BuildTarget.StandaloneWindows64);
    This led to the result that my editor swapped to Standalone, not Android as I expected. The editor threw an error regarding the attempt to emulate OpenGL ES 3.0 while being on a platform which doesn't support it.
    When attempting Build and Run short after, the editor immediately swapped to Android again and built as expected.
    vferguson likes this.
  2. Graham-Dunnett


    Unity Technologies

    Jun 2, 2009
    I'll post this into the docs team list of issues. Can't say how quickly documentation will be changed to make this more clear.
  3. NK-Dmitry


    Nov 10, 2015
    Would you be able to post an answer here with a quick explanation please :)
  4. rcenzo


    Aug 21, 2014
    As I understand it, when you select any of the targets in Build Settings, you technically select a BuildTargetGroup, i.e. Standalone. If that target supports a variety of other platforms, like Standalone, you pick the specific build target you intend to use, like BuildTarget.StandaloneWindows, .OSX*, or Linux. It's usually depicted as another dropdown or two in the Build Settings window.
    waltran likes this.
  5. Orion_78


    Feb 13, 2014
    I made a simple converter for personal use. That way I only define BuildTarget
    Note that I didn't include obsolete BuildTargetGroup

    Code (csharp):
    2.     static BuildTargetGroup ConvertBuildTarget(BuildTarget buildTarget)
    3.     {
    4.         switch (buildTarget)
    5.         {
    6.             case BuildTarget.StandaloneOSX:
    7.             case BuildTarget.iOS:
    8.                 return BuildTargetGroup.iOS;
    9.             case BuildTarget.StandaloneWindows:
    10.             case BuildTarget.StandaloneLinux:
    11.             case BuildTarget.StandaloneWindows64:
    12.             case BuildTarget.StandaloneLinux64:
    13.             case BuildTarget.StandaloneLinuxUniversal:
    14.                 return BuildTargetGroup.Standalone;
    15.             case BuildTarget.Android:
    16.                 return BuildTargetGroup.Android;
    17.             case BuildTarget.WebGL:
    18.                 return BuildTargetGroup.WebGL;
    19.             case BuildTarget.WSAPlayer:
    20.                 return BuildTargetGroup.WSA;
    21.             case BuildTarget.Tizen:
    22.                 return BuildTargetGroup.Tizen;
    23.             case BuildTarget.PSP2:
    24.                 return BuildTargetGroup.PSP2;
    25.             case BuildTarget.PS4:
    26.                 return BuildTargetGroup.PS4;
    27.             case BuildTarget.PSM:
    28.                 return BuildTargetGroup.PSM;
    29.             case BuildTarget.XboxOne:
    30.                 return BuildTargetGroup.XboxOne;
    31.             case BuildTarget.N3DS:
    32.                 return BuildTargetGroup.N3DS;
    33.             case BuildTarget.WiiU:
    34.                 return BuildTargetGroup.WiiU;
    35.             case BuildTarget.tvOS:
    36.                 return BuildTargetGroup.tvOS;
    37.             case BuildTarget.Switch:
    38.                 return BuildTargetGroup.Switch;
    39.             case BuildTarget.NoTarget:
    40.             default:
    41.                 return BuildTargetGroup.Standalone;
    42.         }
    43.     }
  6. UweR7


    Jul 27, 2017
    When you are thinking that the above is confusing, bad documented, etc., try this:

    Code (CSharp):
    1. var a = BuildTargetGroup.iOS;
    2. var b = a;
    "b" is equal to ".iPhone"

    Bug? Any ideas why? Meaning? Background? Documentation?
  7. rcenzo


    Aug 21, 2014
    Because iPhone is the exact same value as iOS, but no longer in use. They usually don't remove values as such, only tell the user they're obsolete and under the hood it handles it regardless.
  8. UweR7


    Jul 27, 2017
    Kidding me, or?
    Changing a value at run time is a total different thing compared to displaying a hint during development that this or that is obsolete.
    This behavior is ridiculously!
    And: ".iPhone" is obsolete NOT ".iOS"!
    So when they change a value without any developer interaction at run time, which is a no go at all, they should change it from ".iPhone" to ".iOS" and not the other way around.

    Why they should never change a value?
    Think about assert/unit tests ...
  9. rcenzo


    Aug 21, 2014