Sharing build information across multiple projects

Since the options files are passed directly to the compiler shell it precludes using build variables or environment variables in them.  I could file an enhancement request to preprocess the options file and to pass one with variable values replaced instead to the shell.  It seems like a reasonable request but I can't comment on when that would be available.

Another option would be to copy your project within CCS.  Just copy paste with in the Project View, it will give you an option to rename the project.  The project will be in a folder with the new name.  That may be an easier way to create a "new" project with your old options.

John

John,

Thanks for your answer, but just creating new projects is not the fundamental problem.   I want to have 10-15 applications and exactly one place to change the compilation and link options for all of those 10-15 applications at once.  (This was trivial with a make-based system through the use of including a common ".mk" file that contained the common definitions and common facilities).

I have something now that works, but it feels like a Rube Goldberg hack:

I have a "library" project where my common code goes.   In that library project directory I create a makefile.targets file that contains the following,

EXPAND_ENV := "$(TK_ST4_DIR)\common\bin\expand.bat"

$(OBJS):  ../ST4_ARM_project.opt

all: ../ST4_ARM_project.cmd ../ST4_ARM_project_debug.cmd ../ST4_ARM_project_release.cmd

%: %.raw
    $(EXPAND_ENV) $< $@

where the expand.bat function uses perl as follows,

@echo off
call perl -wpe "s#\${?(\w+)}?# $ENV{$1} // $& #ge;" %1 > %2

• ST4_ARM_project.opt contains the "common" compiler options I will be using across all my applications (including the library)
• ST4_ARM_project.cmd contains the "common" supporting linker libraries and paths I will be using across all my applications
• ST4_ARM_project_debug.cmd and ST4_ARM_project_release.cmd include ST4_ARM_project.cmd and then have specializations for the Debug and Release (they are simple and basically make sure I am pointed to the correct library for the configuration, and then include ST4_ARM_project.cmd,

Now by changing ST4_ARM_project.opt.raw or ST4_ARM_project.cmd.raw I can make a change that propagates over all of my applications and the library automatically and portably (since the .raw files refer to environment variables that different members of my team can use differently)

In addition, in order for the first build to work (since CCS5 acts irrationally if a command file doesn't exist when the "build" button is hit), the actual command file that is included in the library build is ST4_ARM_base.opt, and it just

--cmd_file=..\ST4_ARM_project.opt

This way I can fool CCS5 into using ST4_ARM_project.opt in the build even though it was not created until the building makefile is invoked (if I use ST4_ARM_project.opt directly, the build dies because CCS5 cleverly realizes this command file doesn't exist and lets it just be --cmd_file= with nothing on the right side).

Now that I've stubbornly gotten something to work the way I want it to, I'll ask again:  given that this is what I want, is this really the only way to do it?   Is there some way to do the same, commonly desired, thing that feels less like a gigantic hack?

Just as an FYI to whom it may concern, I found that using the above makefile.targets increased the random rebuilding of things in support libraries.  It appeared that switching to using a makefile.init instead of a makefile.targets as follows worked more reliably (for no Make based reasons I could see, it just appeared to cut down on the incidences of Code Composer cleaning out objects in my large dependent library for reasons I don't really understand, and which could be coincidental.)

EXPAND_ENV := "$(TK_ST4_DIR)\common\bin\expand.bat"

all: ../ST4_DSP_project.opt ../ST4_DSP_project.cmd ../ST4_DSP_project_debug.cmd ../ST4_DSP_project_release.cmd

%.cmd: %.cmd.raw
 $(EXPAND_ENV) $< $@

../ST4_DSP_project.opt: ../ST4_DSP_project.opt.raw
 $(EXPAND_ENV) $< $@
 $(MAKE) clean

This approach still allows the library to be completely rebuilt if the option file changes, but, sadly, it does it through relying on the order of targets in all (hence the inclusion in makefile.init to make them first rathe than makefile.targets) rather than on rules.   From past experience, this works fine for single threaded make, but could cause weirdnesses if I tried to do parallel makes.   I'm not worried about that right now, but it should be noted.   In general, I prefer the previous, rule-based method, but the previous method interacted in weird ways with the code composer automatic generation of makefiles so that builds of applications that "depended" on this library often resulted in a rebuild all or part of the library when switching applications, even when no source or header files in the library were changed.   That doesn't happen as much with the makefile.init approach  (why?  I don't know), although it still happens occasionally when I switch applications  (why? I don't know).