Ok, this is a rant, I know, but...
I once thought I had read that the new xml-based project file format would allow for multiple targets in which source files could have the same name but reside in different physical folders on disk, but I can't remember where I read it. Perhaps it was a dream?
Why do I want this?
Suppose you have two different boards (hardware) and one software project. There is a set of common files, and a set of support files for each of the boards. The board support files reside in different subfolders on disk, but they have the same file name (for instance ./board1/hardware.c and ./board2/hardware.c). With uVision, it is then impossible to define a target for each of the boards, since all project files are obviously shared between all targets, even regardless of groups. I want uVision to *switch* some files when I switch targets. I am stumped why the designers of uVision hasn't allowed for this.
I know I could use #ifdefs and a global define that belongs to the selected target (in a common file), but that's not a solution I like. Another solution is to abandon uVision and just use make, but then debugging is a hassle.
With the new xml format, it should be very easy to actually do this properly. As I see it, the current implementation is fundamentally flawed.
Regards -Oyvind
> I know I could use #ifdefs and a global define that > belongs to the selected target (in a common file), > but that's not a solution I like. Another solution is > to abandon uVision and just use make, but then > debugging is a hassle.
Don't use defines if you have a powerfull GUI, this will only end up in cunfusing yourself. I once worked on a project like this, and it was horrible. #if, #ifdef, #ifndef, #else, ... You'll end up in mixing positive with negative logic when doing this.
My suggestion: Think about a good common layer, and implement two sets of low level drivers for the two boards. Then - by switching between the targets you can select which subset of LowLevel drivers you want to compile.
Another problem in uVision is, that (I'd say most of the) users do not know the features of uVision.
So - before doing this post here and you will get an answer. There are soo many features implemented most users do not know about.
BR, /th.
I think that's true of most applications.
There is a story that 75% of the suggestions that microsoft received from its "focus groups" were for features that already existed in the products!