Targets live within a project, and by default share any files, settings and references within that project, unless those are explicitly marked as belonging to a specific target.
By default, each project will have one implicit target, named after the mode (and, optionally, submode) set for the project, eg "Echoes", or "Island-Android". For such single-target projects you can pretty much ignore the concepts of targets at all (although you might see the target namne mentioned in build logs).
Additional targets can be defined in a project by providing one or more "
PropertyGroup" tag declaring a specific named target. The property group's
Condition attribute must match the exact syntax shown below (where
TargetName is of course replaced by the name of the target):
<PropertyGroup Condition=" '$(Target)' == 'TargetName' "> ...
Within the property group, standard Project Settings can be providede that will be specific for the target. Much like with
Configuration sections, settings set for a specific target will override the same setting set on project level.
One common use for Targets is to set a separate Mode (and SubMode) in order to build the same project for multiple platforms. But targets can be distinguished by any type of setting – for example it would be entirely valid to have a project that builds for ,.NET, and have several targets that only differ in the SDK version, or on other settings.
My default, all objects declared in a project (in
ItemGroup elements) will belong to all targets. You can limit objects tom a single target by providing a metadata value named
Target on them, set to the name of the target the object belongs to:
<ItemGroup> <Reference Include="System.Whatever"> <Target>Echoes</Targete> </Reference> </ItemGroup>
Again keep in mind that target names do not have to match a platform name (although they often will), but can be any arbitrary string.
One special case (not really tied to targets, per se) that is worth mentioning here is "
#" referendes. The base References used by a project often differ vastly between platforms.
If you add a reference object named "
#" to your project, it will automatically resolve to the common set of base references needed by most projects, for the current platform. Since reference aere resolved by target, a single
# reference item can cover the basics for all your targets, alleviating the need to add many separate references all manually tied to a specific target.
<ItemGroup> <Reference Include="#" /> </ItemGroup>
By default, building a project from the command-line will build all targets, and building the active project from the IDEs will build the active target.
You can manually control what targets to build via the following two EBuild Command-Line Switches:
--targets:<list of target names>
--skip-targets:<list of target names>
Each switch can be followed by a semicolon-separated list of target names.
In Fire and Water, you can also right-click (command-click) each Target in the project tree (underneath the project's main node), and choose which targets to enable and disable.
Please Note that Visual Studio does not currently support multi-target projects, and multi-target project support in Fire and Water is limited to working with existing targets and dows not allow adding, removing or changing targets or their settings, yet.