# 1@prset.hlp>settings ; ARM RVDEBUG Project Template for ARM core tools
#$$$CONFIG=Debug
#$$$CONFIG=Release
#$$$CONFIG=DebugRel
#$$$0COMPILE=arm
#%Release%Compilation.generate_debug=disabled
#%Debug%Compilation.generate_debug=enabled
#%Release%Optimization.debug_optimize=maximum
#%DebugRel%Optimization.debug_optimize=partial
#%DebugRel%Compilation.generate_debug=enabled
#$$$2COMPILE=arm_cpp
#%%Compilation.compiler=ARM_Cpp
#%%Compilation.Checking.source_language=CPlusPlus
#%Release%Compilation.generate_debug=disabled
#%Debug%Compilation.generate_debug=enabled
#%Release%Optimization.debug_optimize=maximum
#%DebugRel%Optimization.debug_optimize=partial
#%DebugRel%Compilation.generate_debug=enabled
#$$$1COMPILE=thumb
#%%Compilation.compiler=Thumb_C
#%Release%Compilation.generate_debug=disabled
#%Debug%Compilation.generate_debug=enabled
#%Release%Optimization.debug_optimize=maximum
#%DebugRel%Optimization.debug_optimize=partial
#%DebugRel%Compilation.generate_debug=enabled
#$$$3COMPILE=thumb_cpp
#%%Compilation.compiler=Thumb_Cpp
#%%Compilation.Checking.source_language=CPlusPlus
#%Release%Compilation.generate_debug=disabled
#%Debug%Compilation.generate_debug=enabled
#%Release%Optimization.debug_optimize=maximum
#%DebugRel%Optimization.debug_optimize=partial
#%DebugRel%Compilation.generate_debug=enabled
#$$$ASSEMBLE=arm
#%Release%Assembly.generate_debug=disabled
#%DebugRel%Assembly.generate_debug=enabled
#%Debug%Assembly.generate_debug=enabled
#$$$ASSEMBLE=thumb
#%%disable=True
#%Release%Assembly.generate_debug=disabled
#%DebugRel%Assembly.generate_debug=enabled
#%Debug%Assembly.generate_debug=enabled
#%%Assembly.assemble_mode=Thumb
#$$$

# The PROJECT group is the main group of all projects. This describes the
# basic information on the project and is used by RVDEBUG to handle project
# control. Most of the fields in this group are pre-filled in and should
# not be modified.
[TEMPLATE=&PROJECT] \\ Defines base project information

# 2@prset.hlp>settings ; The specific_device field allows selective project binding. This
# means that the project will only bind to the named devices if
# any. If none specified, the project will bind to all devices 
# of the processor type the project is for. The name(s) given
# must match the device_names from the JTAG-file. You can specify
# multiple names, and each will be tested. This is useful with
# multi-processor systems where each device has a different
# program to load.
specific_device=LS \\ Name of specific device(s) to bind to

# 3@prset.hlp>settings ; Text description of this project.
description=S   \\ Description of this project

# 4@prset.hlp>settings ; The processor field identifies the processor toolchain that the project is built for.
# This field is filled in automatically when the project is created, and is
# then locked.
processor_=K(ARM-ADS)   \\ Processor toolchain project builds for

# 5@prset.hlp>settings ; The type of project this is. This field is filled in automatically when
# the project is created, and is then locked.
type_=K(Simple,Standard,Makefile,Container)1 \\ Type of project this is

# 6@prset.hlp>settings ; The author field is filled in with the original author of this project, and
# is then locked. This allows for locking by author (only the author can 
# modify it) elsewhere within the project.
author_=S               \\ Name of author of this project

# 7@prset.hlp>settings ; Locking allows the project itself to be controlled. A version lock means
# that the version/source control used for source files will be used for
# project files as well. The project will be checked into the source
# control system by RVDEBUG. Attempts to modify it will automatically
# check the files out. Checking the file in will also allow stamping
# the sources as well. A user lock means that only the author can 
# modify the file (using RVDEBUG).
lock=K(unlocked,versioned,user) \\ Type of lock model for project updates \
                        \K No lock control, \
                           Version/Source Control locked, \
                           Only author can change

# 8@prset.hlp>settings ; The base directory of the project is used to allow all sources and
# build files to be relative to the base (if within it or a sub-directory).
# This way, a copy of the project can be made that is moved to a new base
# and so local modifications can be made. If the path is left empty,
# the base-directory will be the directory of this file.
base_directory=D"<use path of project file>"    \\ Base directory of project

# 9@prset.hlp>settings ; The tool-directory field is one or more paths to find tools to run. These
# will be added to the path environment variable prior to running any
# tools.
tool_directory=D        \\ Location for all tools (by default).

# 10@prset.hlp>settings ; The tool-envvar fields are used to define environment variables that
# should be set prior to running any tools.
tool_envvar=LS  \\ Environment variables needed by tools

# 11@prset.hlp>settings ; Source search paths allows setting the list of directories to
# find sources. This is only needed when the compiler/assembler
# does not pass the source paths through to the debugger. You
# know you need this when the debugger cannot find the source
# files automatically.
source_search=LD        \\ Source search paths for debugging

# 347@prset.hlp>settings ; Source mapping paths allows setting the list of directories to
# find sources when projects are moved from their original location.
# This is only needed when the compiler/assembler
# does not pass the current source paths through to the debugger.
source_mapping=LL      \\ Source mapping paths for debugging

# 12@prset.hlp>settings ; Command Open/Close allows you to specify a set of RVDEBUG 
# commands to run when the project is opened (and connected to
# target) or closed (if still connected). This may be any 
# command including loading a command file ("inc" command).
# Common examples for open are "reload" to immediately load 
# the file and also breakpoint setup and macro setup. Common
# examples for close are "del macro" to delete macros created
# for a project.
{.Command_Open_Close \\ Commands to run when project is opened or closed
  # 13@prset.hlp>settings ; 
  open_conn=LS  \\ RVDEBUG commands to run on project open/connect
  # 14@prset.hlp>settings ; 
  close=LS              \\ RVDEBUG commands to run on project close
}

# 15@prset.hlp>settings ; The modification history is built automatically each time the project
# is edited. It contains the user, date, and type of modification that
# took place.
{Modification_History \\ History of changes
  # 16@prset.hlp>settings ; 
  user_=S               \\ Name of person changing
  # 17@prset.hlp>settings ; 
  date_=S               \\ Date changed
  # 18@prset.hlp>settings ; 
  type=K(created,added_to,deleted_from,other)0 \\ Type of change
  # 19@prset.hlp>settings ; 
  description=S \\ Description of changes
}

[INCLUDE] ?prj_set.stp
# 42@prset.hlp>settings ; The CONFIGURATION group contains configurations for building
# the same application multiple ways. The common use is for a
# debug build vs. release build. But, this can also be used for
# different optimization levels, different variants (such as
# different device drivers), etc.
[TEMPLATE=&CONFIGURATION] \\ Defines configurations
# 43@prset.hlp>settings ; 
config=LS               \\ configuration - 1st one is default
# 44@prset.hlp>settings ; Active Config allows selection of which configuration should be
# built and loaded. This can be changed here as well as within
# the debugger.
active_config=K($TEMPL_GROUP=config=)0 \\ active configuration to use
# 45@prset.hlp>settings ; The normal rule for configurations is to put objects and the
# output executable/library in a sub-directory with the same name
# as the configuration (such as "debug"). This field allows changing
# that rule. Note that if you remove sub-directories such that objects
# from multiple configurations go to the same output location, you must
# be certain that the object files would be the same regardless of
# which configuration would build them.
subdir_rule=K(Config_name,None,Auto)0 \
                        \\ Rule for creation of output sub-directory \
                        \K Use Configuration name,\
                           Do not use configuration sub-directory,\
                           Use Config name if no sub-directory specified in project
# 170@prset.hlp>settings ; The CUSTOM group contains rules for building headers (such as
# .h files), sources (.c, .asm, .cpp), objects (.o or .obj),
# libraries (.lib or .a), tools that will be run by other
# CUSTOM groups or for pre/post-link, etc. Each CUSTOM group
# can build one or more files. The files listed under the
# 'files' entry are the explicit output. So, if a source and
# header are produced, only one should be listed and it should
# be the one that something else is dependent on. If multiple
# files are listed via the 'files' entry, the custom command
# will be run once for each. The 'dependends_on' fields are
# used to name specific files that control the building of
# these files. For example, if the command processes a data
# file (say coefficients) and produces a source file, the data
# file should be listed. Each time the project is built, the
# date/time of the data file will be compared against the output
# file and if the data is newer, the output will be rebuilt.
[TEMPLATE=CUSTOM]       \\ Custom tools

# 171@prset.hlp>settings ; Removes this group from the build
disable=B0              \\ Removes this custom group from build \
                        \C (,$<DIS=1>)

# 172@prset.hlp>settings ; 
description=S   \\ Describes tool

# 173@prset.hlp>settings ; 
message=S               \\ Any messages to emit when running \
                        \C ?* $<SPC=$VALUE>

# 174@prset.hlp>settings ; The files list the main output file from the command. If
# the command produces more than one output file, only list one
# of them below. Use multiple files only if you want the command
# run once to produce each file. Use a fake filename (one that is
# not produced) if you want this command to run every time (but
# see also pre-link and post-link).
files=LF                \\ Files to process with command (one per) \
                        \C ?* $<OBJ=$VALUE>

# 175@prset.hlp>settings ; Depends_on lists files that are used as inputs to building
# the output file(s). The date/time of these files will be
# compared against the output file to determine if it should
# be rebuilt (if any depends_on file is newer, it will be
# rebuilt).
depends_on=LF   \\ List of files that are dependents \
                        \C ?* $<SRC=$VALUE>

# 176@prset.hlp>settings ; Command is the host command (or commands) to run to produce
# the output file or behavior. You can use various macros "$(name)"
# in the command. The common macros are "$@" for the output file,
# "$?" is list of depends_on files that are newer. Commands
# that use shell commands (e.g. echo and for) should be preceded 
# by a "+" (plus sign). A preceding "@" (at sign) will prevent
# echoing of the command before running it. So, "@+echo foo"
# will just write "foo" on the output.
command=LS              \\ Command to run including all arguments \
                        \C ?* $<EXE=$VALUE>

# 177@prset.hlp>settings ; Use_as determines when and how the output files should be
# rebuilt. A link_dependent means that this output will be
# checked (against its depends_on files) for rebuild whenever
# you build. Link_input indicates that the output file is
# an input to the linker (and object file or equivalent).
# Named target means that the output file is only checked if
# some other file depends on it or it is named in a build.
# This latter case is used when the output file is a .h or
# .c/.asm file that is used as input for a COMPILE/ASSEMBLE
# group as well as when it is input to another CUSTOM group
# (so you can chain build custom files).
use_as=K(link_dependent,link_input,named_target,post_link)0 \
                           \\ Form of output of this command \
                           \K Will be checked for build each time, \