On 31/01/2019 17.58, Ben Craig wrote:
> Your IDEs and tidying tools and anything else that needs to consume
> and understand your source without building it will care. If you
> want types and values to have different colors in your IDE, then your
> IDE needs to be able to get from your file to the source file that
> declared those entities.

(That said, it seems to increasingly be the case that the way they do
this is by... querying the build system and using the compiler to parse
your sources. At least, the IDE's that work *well* do it this way...)

> I will go further and say that a significant portion of C++ projects
> rely on file globbing to even gather the list of .cpp files to
> compile.

At least in CMake, this is... strongly discouraged. For native Visual
Studio projects, I believe it's not even possible. The problem with this
approach is that a) it's brittle unless you re-run the build generation
tool on *every* build, and b) it breaks if you happen to have things
that look like source files lying around that shouldn't be compiled. (At
least for me, the latter is fairly common; I frequently have "WIP"
sources lying around that are not in a buildable state.)

Also, explicitly listing source files tends to make it much more obvious
when you forget to add a file to the VCS :-).

> We should at least be aware of this cost and consider it, before
> requiring everyone to duplicate the build information that already
> exists in their source files and file system.

Indeed; *DRY*¹. Lists of sources are somewhat exceptional, for various
reasons (per above), but dependencies (includes, modules) really should
not need to be repeated, and they tend to change much more frequently
and be much more difficult to spell out manually.

(¹ I would hope everyone reading this knows DRY, but:
https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)

-- 
Matthew