I find that having a "standard" project directory with sub-directories for all projects to be of great value.
I do not know what others have done when they start a new project, but I can tell you that I simply copy-n-paste, then rename this "template" into my ..\Projects\ directory, and then work from within the template's standardized structure.
e.g. ..\Projects\Alpha
Where "Alfa" is the renamed standardized structure.
I will add sub-directories to this standard structure when it is deemed appropriate. I highly recommend this structure to people who work on multiple projects and add this bit of advice to their methods.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
[ It figures: I meant to say Alpha again and not Alfa ]
Because uVision defaults its file searches as relative to the Project file location, it makes sense to have the uVision project in a folder immediately above the source folder(s).
Also, Keil tools support having a folder to object files, and a folder for listings - so it makes sense to take advantage of these...
Ack!
I always have:
project project\src project\obj project\lst
Then it is also easier to delete object files when sending a project by email or adding it to my svn server.
. BR, /th.
you are missing project\bld (which would include obj and lst)
the only reasonable way to create projects is to copy first 'standard' stuff into the bld directory, then 'common' stuff' (what is common for all types of this group of units) then (while renaming) the unit unique stuff and then building from .bld.
this allow for e.g. the definition of U8 and TCON to exist only once on your whole disk and allow for producing a group of similar builds without having the same stuff copied 47 times.
the advantage of this system is that you never 'forget' a change simply because you NEVER have to make a change min more than one file
Erik
No, it is certainly not the only reasonable way - there are other perfectly reasonable ways.
eg,
project project\common project\variant1\src project\variant1\obj project\variant1\lst project\variant2\src project\variant2\obj project\variant2\lst etc...
project project\common
project\variant1\src project\variant1\obj project\variant1\lst
project\variant2\src project\variant2\obj project\variant2\lst
the trap is right there, variant 1 and variant47 will have some identical files. thus if a change is made it has to be made 47 times
In that case, they would go in "common". Or perhaps you'd have a "feature-x" folder, which would be used by all variants having that feature. Or a library.
The problem I see with your scheme is: when there's just one bld folder, how do you know which variant it actually is?
However, if you really have 47 variants, then you really should be using a proper configuration management tool.
In that case, they would go in "common". what about what is common for build3, build 11, build14 ... but not all builds
However, if you really have 47 variants, then you really should be using a proper configuration management tool. which I do (a very elaborate .bat file that does it all)
"common" would be anything shared by more than one build - so "shared" might be a better name.
Or, as I said, you could also have other "groups"
project project\common -- Sources common to ALL builds project\feature-a -- Sources common to builds with Feature 'A' project\feature-b -- Sources common to builds with Feature 'B' project\feature-c -- Sources common to builds with Feature 'C' project\variant1\src -- Sources unique to Variant 1 project\variant1\obj -- All objects from building Variant 1 project\variant1\lst -- All objects from listings Variant 1 project\variant1\src -- Sources unique to Variant 1 project\variant1\obj -- All objects from building Variant 2 project\variant1\lst -- All objects from listings Variant 2
Andy, how would you the above with ONE 'project file' not 47 to maintain? I only have one .bat for building all 47 versions
in the top, 'project', folder.