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.
"...I simply copy-n-paste, then rename this "template" into my ..\Projects\ directory ..."
All standard stuff.
We have the procedure described in our firmware creation checklist Volume#7, Chapter#9, Section#28, Sub-Section#12, Point#12. We are then pointed to Addendum Volume#12, Chapter#27, Section#98, Sub-Section#4, Point#14.
(Those contractors really knew how to do it properly.)
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
I wasn't thinking on the "minor" scale of just the code-monkey's working directory and its possible IDE sub-directories, but rather for the project as a whole...
E:\ACME\ENG\PRJ\WIDGET\ +-\Docs { All project documentation } | +-\Elect\Released { All electrical stuff here } | \Rev- { Officially Released Schem } | \RevA { Revision Lists } | \Rev[etc] | \Work { Working directory for elex} | +-\Mech\Released { All mechanical stuff here } | \Rev- { Officially Released DWGs } | \RevA { Revision Lists } | \Rev[etc] | \Work { Working directory for mech} | +-\PDFs { Actual data-sheets or a short-cut to a dBase of data-sheets } | +-\Pics { Photos, graphics, and other images for the project } | +-\PLDs\Released { Officially Released Schem } | \Rev- { VHDL, Verilog, CUPL, ABLE, etc } | \RevA { Officially Released HDLs } | \Rev[etc] { Revision Lists } | | \Work { Working HDL code directory } | \ { FPGA IDE Derived Directories } | \ { FPGA IDE Derived Directories } | \ { FPGA IDE Derived Directories } | +-\Sim\Released { Officially Released Sims } | \Rev- { Officially Released Sims } | \RevA { Revision Lists } | \Rev[etc] | \Work { Simulation working directory (SPICE/Simulink/etc) } | +-\Soft\Released { Officially Released Software } | \v0_00 { Officially Released code } | \v1_21 { Revision Lists } | \v[etc] | \DFDs { UML/[pick your flavor] documentation } | \FQT { Formal Quality Testing needs } | \Master { in a Master/Slave scenario } | \Released { Officially Released Master Software } | \v0_00 { Officially Released Master } | \v1_21 { Revision Lists } | \v[etc] | | \Work { Software working directory (C/C++/ASM/etc) } | +-\Specs { Specifications, eg ANSI XYZ, NEMA, etc } | +-\Test { Testing Plans and results } | +-\Weblinks { Worth-while website short-cuts } | +-\[as needed: e.g. corrispondance] | +-\[as needed: e.g. Slideshows]
For the '\Work' directories, I personally allow the .C .ASM .LST .MAP .SRC .OBJ all reside within the same "\Work" directory. My Editor (CodeWright 7.5) can segregate them for me. I don't really care if these IDE generated files are separated into their own folders. (Should I?)
Dear [Flat] Black, You are right, it is in Checklist Volume#7, Chapter#9, Section#28, Sub-Section#12, Point#12. We are then pointed to Addendum Volume#12, Chapter#27, Section#98, Sub-Section#4, Point#14.C.
in the top, 'project', folder.
I was wondering what other people have for their 'standard' project directories.