sarm_prj.stp

realview22.rar

# 623 ; 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

# 570 ; 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

# 497 ; Text description of this project.
description=S   \\ Description of this project

# 536 ; 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-SDT)   \\ Processor toolchain project builds for

# 510 ; 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

# 477 ; 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

# 667 ; 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

# 558 ; 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

# 590 ; 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).

# 476 ; 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

# 725 ; 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

# 560 ; 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

# 589 ; 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
  # 724 ; 
  open_conn=LS  \\ RVDEBUG commands to run on project open/connect
  # 496 ; 
  close=LS              \\ RVDEBUG commands to run on project close
}

# 687 ; 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
  # 537 ; 
  user_=S               \\ Name of person changing
  # 440 ; 
  date_=S               \\ Date changed
  # 499 ; 
  type=K(created,added_to,deleted_from,other)0 \\ Type of change
  # 461 ; 
  description=S \\ Description of changes
}

[INCLUDE] ?prj_set.stp
# 625 ; 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
# 621 ; 
config=LS               \\ configuration - 1st one is default
# 408 ; Active Config allows selction 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
# 602 ; 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
# 547 ; 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 explcit 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

# 487 ; Removes this group from the build
disable=B0              \\ Removes this custom group from build \
                        \C (,$<DIS=1>)

# 614 ; 
description=S   \\ Describes tool

# 427 ; 
message=S               \\ Any messages to emit when running \
                        \C ?* $<SPC=$VALUE>

# 682 ; 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>

# 400 ; Depends_on lists files that are used as inputs to building