> what if you start writing a new source file that you don't want to compile and link until it's ready and needed? What makes using a different top-level direc

> what if you start writing a new source file that you don't want to compile and link until it's ready and needed? What makes using a different top-level directory (which is something that would work with nearly all build systems) inconvenient? But if you really want these not-to-be-compiled-yet files nearby in the directory tree, customise the rule to, e.g., not compile anything having a filename beginning with IGNORE, or in a subdirectory called IGNORE, or (if you want to get fancy) listed in a .compileignore file (a la .gitignore). If the number of exceptions is small, then explicitly marking them in any of these ways is DRYer (= requires less maintenance) than explicitly recording the larger number of "business as usual" cases a second time. > An IDE can use actual file lists and its internal project configurations If you rely on an IDE to this extent, it's effectively part of your build system. (Which is absolutely fine, and has some benefits, though also some downsides.) Provided that the IDE is "doing the work for you" (e.g., by adding each new .cpp file you create to the list of files to compile, until you uncheck a box somewhere that removes it), you're good. The only questions then are (1) whether this IDE configuration info is handled sanely by the VCS, and (2) whether it's readily understandable and usable to someone without the IDE (e.g., a CI build server). If the IDE stores this info in an externally defined plain-text build script like a Makefile or Maven pom.xml, then the answer to both questions is probably "yes" -- but, depending on how expressive the build script language is, it might be difficult or error-prone for the IDE to be able to update it reliably if the user makes their own changes to it as well.