s566_prj.stp

realview22.rar

# [e-mail]>settings ; The PROJECT group is the main group of all projects. This describes the
# basic information on the project and is used by ASPEX 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
# [e-mail]>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
# [e-mail]>settings ; 
description=S           \\ Description of this project
# [e-mail]>settings ; 
processor_=K(566*0x)\\ Processor project builds for
# [e-mail]>settings ; 
type_=K(Simple,Standard,Makefile,Container)1 \\ Type of project this is
# [e-mail]>settings ; The author field is filled in with the original author of this project.
# This allows for locking by author (only the author can modify it).
author_=S               \\ Name of author of this project
# [e-mail]>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 ASPEX. 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 ASPEX).
lock=K(unlocked,versioned,user) \\ Type of lock model for project updates\K\
                        No lock control,Version/Source Control locked,\
                        Only author can change
# [e-mail]>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.
base_directory=D"<use path of project file>" \\ Base directory of project
# [e-mail]>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).
# [e-mail]>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
# [e-mail]>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
# [e-mail]>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
# [e-mail]>settings ; Command Open/Close allows you to specify a set of ASPEX 
# 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
  # [e-mail]>settings ; 
  open_conn=LS          \\ ASPEX commands to run on project open/connect
  # [e-mail]>settings ; 
  close=LS              \\ ASPEX commands to run on project close
}
# [e-mail]>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
  # [e-mail]>settings ; 
  user_=S               \\ Name of person changing
  # [e-mail]>settings ; 
  date_=S               \\ Date changed
  # [e-mail]>settings ; 
  type=K(created,added_to,deleted_from,other)0
  # [e-mail]>settings ; 
  description=S         \\ Description of changes
}

[INCLUDE] ?prj_set.stp
# [e-mail]>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 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 'depends_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
# [e-mail]>settings ; 
disable=B0              \\ Removes this custom group from build \
                           \C (,$<DIS=1>)
# [e-mail]>settings ; 
description=S           \\ Describes tool
# [e-mail]>settings ; 
message=S               \\ Any messages to emit when running \
                           \C ?* $<SPC=$VALUE>
# [e-mail]>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>
# [e-mail]>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>
# [e-mail]>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>
# [e-mail]>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 (an 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, \
                              Will be used as input to linker (object), \
                              Is only a target in makefile, \
                              Will be built after link \
                           \C $<PRV=$VALUE>
# [e-mail]>settings ; The COMPILE group contains the C and C++ sources to be compiled in the
# project. The default build (COMPILE=default) contains the normal build
# rules for all sources. If some sources need to be compiled differently,
# a new COMPILE group can be created that contains these alternate
# rules.
[TEMPLATE=COMPILE]      \\ Defines compilation rules \C -c
# [e-mail]>settings ; 
disable=B0              \\ Removes this compile group from build \
                           \C (,$<DIS=1>)
# [e-mail]>settings ; The file list contains the list of sources to compile with for this
# compile group. These should only be C and C++ sources.
files=LF(Sources [*.c;*.cpp],$CWD) \\ Source files to compile \
                           \C{*} ? $<SRC=$VALUE>
# [e-mail]>settings ; The obj-location field contains information on where the object files
# should be placed relative to the sources. The default is to put the
# objects in the base directory of the project. An alternate is to put
# them in a subidrectory of the base. Another alternate is to put them
# in the same location as the sources or a sub-directory of the sources.
# If a sub-directory is chosen, the obj_sub name is used; if not given,
# "objects" is used. The source directory choice will use the same
# directory as each source or a sub-directory of that source if obj_sub
# is filled in. The sub-directories will be automatically created.
obj_location=K(local,sub_dir,same_as_source)0 \\ Where to put object files\K\
                        In project base directory,\
                        In object subdirectory from base,\
                        In source directory \
                        \C (,-fr [$"obj_sub",$"obj_sub",objects]\
                             $<OBJ=[$"obj_sub",$"obj_sub",objects]>\
                             ,-fr $$SPA/$"obj_sub" $<OBJ=$$SPA/$"obj_sub">)
# [e-mail]>settings ; If the object location is selected as sub_dir, this specifies the name
# of the sub-directory.
obj_sub=S               \\ Sub-directory name for output (if not local) \C
# [e-mail]>settings ; Extra-args is used to add special compiler switches not controlled
# below.
extra_args=S            \\ Any extra Compiler arguments to use \
                           \C ?* $VALUE
# [e-mail]>settings ; The tool directory specified in the project or tool location file
# will be used to find the compiler. The name of the compiler is
# given in the tool location file. If you want to use a different
# location or name, you can set tool_path here.
tool_path=F(EXE)        \\ Pathname of compiler if different than tools \
                           \C ? $<EXE=$VALUE>
# [e-mail]>settings ; Preprocessor switches control the operation of the compiler when
# processing "#if" and "#include" directives. These can be used to control
# exactly how the source is compiled and where headers come from.
{.Preprocessor          \\ Preprocessor switches
  # [e-mail]>settings ; The include list contains the directories to search for include files
  # when compiling. The default is "." for quoted includes and the tool
  # path for <> includes.
  include=LD            \\ Include paths to search \
                           \C ?* $<PRV=-I$VALUE>
  # [e-mail]>settings ; 
  define=LS             \\ Define macro name as name or name=value \
                           \C ?* -D$VALUE
  # [e-mail]>settings ; 
  undefine=LS           \\ UnDefine macro names \C ?* -U$VALUE
  preserve_comment=B0   \\ Preserve comments in output \C (,-C)
}
# [e-mail]>settings ; The listing switches control what kinds of output listings are created
# by the compiler or assembler.
Listing=LF              \\ Listing controls     \
                           \C ?* -l$VALUE

# Error and Warning can be set for different levels of information to
# be shown during compilation.
{.Warning_Control       \\ Control of warnings and error-detection
  extra=B0              \\ Warn for select events (see manual)  \C (,-W)
  implicit=B0           \\ Warn whenever a function is implicitly declared \
                           \C (,-Wimplicit) 
  return_type=B0        \\ Warn when a return type defaults to integer  \
                           \C (,-Wreturn-type)
  unused=B0             \\ Warn of unused local variables               \
                           \C (,-Wunused)
  switch=B0             \\ Warn if switch lacks case for enumerated type\
                           \C (,-Wswitch)
  all=B0                \\ Warn for any condition listed above  \
                           \C (,-Wall)
  comment=B0            \\ Warn when '/*' appears within a comment \
                           \C (,-Wcomment)
  id_clash=S            \\ Warn if two identifiers match first LEN characters \
                           \C ?* -Wid-clash-$VALUE
  shadow=B0             \\ Warn if local variable shadows another local \
                           \C (,-Wshadow)
  trigraphs=B0  \\ Warn if any trigraphs are encountered        \
                           \C (,-Wtrigraphs)
  {.Pointer             \\ Pointer related warnings
    arithmetic=B0       \\ Warn about dependencies on sizeof() function type or void \
                           \C (,-Wpointer-arith)
    casts=B0            \\ Warn whenever a pointer cast removes a type qualifier \
                           \C (,-Wcast-qual)
  }
  string_constants=B0   \\ Warn if address of const char[] is copied to char *  \
                           \C (,-Wwrite-strings)
  inhibit=B0            \\ Inhibit all warning messages (override setting)      \
                           \C (,-w)
}
# Optimizations control how aggressively the compiler tries to improve
# the output machine code. Some optimizations will control what it can
# safely assume about the source code and some will control what kinds
# of optimizations it can use. Note that optimizations can make debugging
# much more difficult.
{.Optimizer             \\ Control of optimizations
    assembler=B0        \\ Run assembly language optimizer on g566c output \
                           \C (,-alo)
    address_constants=B0        \\ Force address constants into registers  \