A source directory (typically src or Source), that houses the projects code, and basically everything you/I want under version control. Structure varies but I tend to create modular bundles out of habit.
A build directory (typically Build/Architecture/OS or Build/Architecture.OS), that houses all essential build time files for that configuration, that won't be distributed. I test builds against multiple Operating Systems, and synchronise the work directory between machines; so being able to have builds of each concurrently tucked away is a bonus. Sometimes I go further and subdivide the build tree into different configurations, such as Release/Optimised/Debug builds, but I rarely have need to.
A distribution directory (typically Dist/Architecture/OS or Dist/Architecture.OS), that contains all the files needed for a user to simply extract to a folder on that given system, and run the program. Worth while for me, for the same reasons as the build tree, plus the added benefit of simple a zip/tar installation!
Sometimes I also create a fourth tree called 'Vendor' or 'Deps', that functions like the source tree, but instead contains the code for whatever libs are required. Plus customised project files/build scripts to compile them when needed.
Like wise, I'll often have an associated set of FILES in the top level, and a documentation directory providing all pertinent information. I particularly pay attention to writing down notes about boot strapping builds, and porting the system to a new environment; because you never know when the next sap sending patches will be you.
Oh so many people ship IDE project files that reek of laziness or brain damage. Me, I'm so damn lazy that I don't want to have to explain it, in fact, I don't even want to edit it later. I just want the thing to *work* when I tell it to build sth. It takes time to do it that way, but it is usually worth it. At least, for cross-platform freaks like me.
Programming is a subject that I do take seriously.
No comments:
Post a Comment