Now I know where to look, this relative link issue and change processor may be easier to fix (by hand) than I thought
Looks like 'relative links' means -- change the make to include information on the source but don't copy it
E.G. # Add inputs and outputs from these tool invocations to the build variables
C_SRCS += \
C:/Users/smithmr/Desktop/CCES_for_511_515_653/uTTCOS/uTTCOS2013/uTTCOS_OSFiles.c \
C:/Users/smithmr/Desktop/CCES_for_511_515_653/uTTCOS/uTTCOS2013/uTTCOS_OSFilesProcessorDependent.c
and I could change the processor type easily within the line
| cc21k.exe -c -file-attr ProjectName="SHARC_uTTCOS" -proc ADSP-21469 -flags-compiler --no_wrap_diagnostics -si-revision any -g -D_DEBUG -I"C:\Users\smithmr\Desktop\CCES_for_511_515_653\uTTCOS\SHARC_uTTCOS\system" -structs-do-not-overlap -no-multiline -warn-protos -double-size-32 -swc -gnu-style-dependencies -MD -Mo "$(basename $@).d" -o "$@" "$<" |
That means -- if really desperate at the end of a bad day, I could, in principle, force CCES to build a blacfin version of the project while still displaying its a SHARC project
I also think that examining the makefile might help me clear up some of the other streams I have initiated -- e.g. can't find executable after renaming
For example -- surpressing verbose mundane output in console window during make of a large number of files
Would having CCES do -- make makefile > null -- cause the mundane message (stdout) to be suppressed and the error messages (stderr) to appear (I never get these, merely asking for the sake of my students :-) )