We are using uV 5.31 and MDK. We have a project developing the software for an embedded device - this software includes bootloader, application software, FCC test code, UL test code, possibly one or 2 others. All are based on the same framework packages and such, and share various modules we wrote. Because of that, it seemed simplest to make each of these a different target in the same project, with each target having its own source group. The contents of those source groups all draw from the same source directories and there is a good amount of overlap - some files are exclusive to a single group, but some are used by all, and there are various combinations in between. All the targets use the same compile options, but some use different target memory areas, which shouldn't affect the object files, just the link. Because of that and the fact that all share a UVBuild directory, I assumed that sources would build as necessary to common (shared) .o files, and the multiple targets would behave the same as a single target with respect to rebuilds - don't rebuild if the source file (and its dependencies) didn't change. But it doesn't. Just the presence of a second target (and/or source group) forces each file in the source group of the current target to have its object file renamed and to rebuild each time. (The framework packages do not rebuild.) Searching about this, I find reference (years ago) to this happening if the target option "Use Cross-Module Optimization" set, but this is not set. Is there some other option causing this behavior or some configuration change we can make to fix it?
TedG said: Because of that and the fact that all share a UVBuild directory
I strongly suspect that that is your actual problem.
Output files from multiple build targets should never go in the same directory. Doing that is almost certain to introduce at least one of two issues: 1) object files from one target being incorrectly used for another,even though they should be different, or 2) everything gets recompiled every time you change between targets, because that's the only sure way to avoid issue 1).
This makes no sense to me. I am building the same source files with the same build options, intending to link them into different targets. On what possible basis would these be incorrectly used? I can't say that I've ever used a build system that wouldn't allow object files to be shared by different targets. A few systems were smart enough to track the build environment and options with each derived object to ensure matches, while others depended on the developer knowing what they were doing. But none out and out forbid it.