I've checked quite a few related questions on source tree organization, but couldn't find the answer for my exact need:
- How should I organize my source tree?
- What's the best structure for a repository?
- How do you organize your projects folders?
For a project I'm working on, my source tree is organized this way
build: all build scripts and resources required by continuous integration
src: all first-party source code and IDE projects of our team
test: all the code and data required for automated tests
thirdparty: all external dependencies
_original_: all downloaded open-source library archives
libthis: unzipped open-source lib with possible custom changes
So far I've been building our first-party build products right in the
src folder inside each IDE projects, such as Visual Studio and Xcode; and build the third-party products in their own working copy folders.
However, this reveals several drawbacks, e.g.:
- In order to accommodate the variety of dependency locations, the lib search paths of the first-party IDE projects become messy
- it's hard to track the output products through the file system
So I'd love to centralize all the build products including dependencies and our first-party products, so that
- the build products don't mess up the repo SCM tidiness
- all the targets and intermediates are easy to rebuild, archive, or purge
- it's easy to track down to the sub source tree of the products from file system
I've tried to create another folder, e.g.,
thirdparty folder so that it looks like this
_prebuilt_: holding build products from all thirdparty libs for all platforms
One complaint I have towards this scheme: mixing derivatives with working copies (lib...) and archives (original) forces me to make folders of derivatives and archives stand out by naming them with ugly markups, in this case underscores (_).
Another idea is to use a universal folder right at the root of the repo and have all the artifacts of dependencies and project products sit there in a jumble. But then, it sounds messy and would be hard to track the artifacts' sources.
Either way, some post-build scripts must be set in action to move artifacts out of their original working copies.
In general, what would be the best practice to organize the build products? Any justifications?
I'd love to achieve at least the goals in the Intentions above.