Best practice for organizing build products of dependencies and project code in your repo source tree?

Question

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
  • libthat: ...
  • ....

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.

Problem

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

Intentions

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

Current Ideas

I've tried to create another folder, e.g., _prebuilt_ under thirdparty folder so that it looks like this

• thirdparty
  • _original_
  • _prebuilt_: holding build products from all thirdparty libs for all platforms
    • platform1
    • platform2
    • platform3
    • ....
  • libthis
  • libthat
  • ...

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.

Question

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.

Answer 1

Many build tools nowadays support "out of source" builds, where the intermediate and final build artifacts are stored in a location outside of the source tree. This is comparable to your idea of a folder at the root of the repo.

But this central folder does not have to contain a jumble of files. You could also organize it like this:

• artifacts
  • libthis: Build artifacts from libthis
  • libthat: Build artifacts from libthat
  • project: Build artifacts from your own project

That should meet your objectives.

As a side note, a common convention when using out-of-source builds is to put the build artifacts in a folder called build. I used artifacts above because you already have a build folder for a different purpose, so that is something to be aware of when you see a build folder being referenced.