18

In my (primarily C++) development, I have long adhered to using out-of-source builds. That is, my source usually sits in a /project/src directory and the builds live in a /project/build/bin/release, /project/build/bin/debug directories. I have done this because it keeps my source directories clean from intermediate files, I have one location for all of my binaries, packaging is easier, cleaning is easier, and version control is easier. (Did I miss anything?)

I am inheriting a (large) project now that uses in-source builds. What is the motivation for this type of structure and what are its advantages? (I am most concerned with engineering-level reasons vs. personal preference types of reasons.)

I was hoping Lakos' "Large-Scale C++ Software Design" would have weighed in on it, but I missed it if it did.

DiB
  • 467
  • 3
  • 9
  • This reads a bit like a rant. What kind of answer would satisfy you? – Daniel Pryden Feb 06 '18 at 18:30
  • 3
    Apologies. I’m looking for “In source builds improve ‘x’” or “they help with ensuring ‘y’” or “automated tests can then ‘z’”. Not a rant. I’m specifically not wanting to get into a war of opinions here! – DiB Feb 06 '18 at 18:34
  • I'm not really a C++ guy, but my experience with C projects is that in-source builds are much more common. More generally, though: any build you do for release needs to be a clean build from a fresh checkout of source, so from a release engineering point of view I don't think it makes too much of a difference? – Daniel Pryden Feb 06 '18 at 18:40
  • I think it’s a language-agnostic question. How can, generally, in-source builds aid the engineering on a project. – DiB Feb 06 '18 at 19:00
  • 14
    In-source builds are a curse you owe to the laziness of your predecessor. They are awful for about everything (source control, cross-building, text-finding, etc.) but are incredibly easy to create using bare makefiles. Sorry, this was a rant. But an *objective* one. –  Feb 06 '18 at 19:48
  • 1
    What exactly do you mean by "in-source" builds? Something like `/project/src/bin/release`, or really all intermediate and output files in `/project/src`? The latter can be indeed a mess if there are more than a dozen source files, the former is ok. – Doc Brown Feb 06 '18 at 19:50
  • 1
    Here I was thinking if "in-source" as the latter: `/project/src`. While a mess, is there an engineering reason that justifies it? It was certainly done (by many projects) for a real _reason_, right? – DiB Feb 06 '18 at 19:54
  • 2
    @Tibo, it is not only incredibly easy with makefiles, but seems to be the default with most IDEs as well (at least when I checked last a few years ago). – Bart van Ingen Schenau Feb 06 '18 at 19:58
  • 5
    @BartvanIngenSchenau Really? what IDE have you been using where this is the case? Qt doesn't do this, in fact it seems to put the build as far away as possible as it can from the source, Eclipse doesn't do this, You might argue that Clion sort of does this, but only as a consequence of `main.cpp` initially being in the top level of your project, it still creates a separate cmake build directory away from your source at that top level. I believe MSVS is similar to Clion in this regard as well. – Krupip Feb 06 '18 at 20:58
  • 2
    @snb: I was using MS Visual Studio and its predecessors regularly over more than 20 years, and the default was always to have some separate folders for output files (though the concentions how and where those folders were placed differed slightly between older and newer versions and programming languages). – Doc Brown Feb 07 '18 at 06:34
  • This is a good question. I was also unable to find any historical reason, such as "simpler for early debuggers to find source files", or "intermediary artifacts (e.g. generated headers) built along the sources to be easily included"... – YvesgereY Sep 05 '19 at 17:02
  • The only real motivation to use in-source-tree builds is that the MS toolset doesn't really support other workflows. So, you're kinda stuck with them if you wan to use VS (to its full extent) https://stackoverflow.com/questions/70766694/making-visual-studio-2019-see-the-git-repo-present-in-source-but-not-in-the-buil/70768159#70768159 ; https://stackoverflow.com/questions/3261596/why-are-out-of-source-builds-not-the-default/ There are also MS-brainwashed answerers who say `src/build` is "out of source", but that's only so in MS lingo/mindset. – Fizz Jan 19 '22 at 11:28
  • Ibid for the `.vs` folder https://developercommunity.visualstudio.com/t/impossible-to-relocate-vs-folder-out-of-source/896935 – Fizz Jan 19 '22 at 11:31

1 Answers1

17

After asking the community here and continuing my search online, I have not been able to find significant engineering justification for using in-source builds. (There are many examples of reasons to avoid them.)

The only objective reason I have found (as alluded to in the comment by @BartvanIngenSchenau) is that in-source builds are sometimes defaulted to by a build system. Because of this default, they require no overhead in setup time, which may be perfectly acceptable for a very small (or scratch) project.

DiB
  • 467
  • 3
  • 9