(Apologies for misthreading; I, too, seem to be missing a non-trivial
chunk of messages being sent to this list :'(.)

On Friday, February 1, 2019 1:10 PM, Gabriel Dos Reis wrote:
> With modules, I expect the number of files need needing scanning for
> dependency to be small. Of course if you adopt a programming style
> that conflates modules with Java classes, where you get one module
> per class, you get what you ask for…

Wasn't that the point of modules? My impression was that modules are
intended to deprecate #include, which would result in very few files
that do *not* depend on at least one module.

...or am I missing something in the above?

> - If I apply that same practice to modules, would I need to scan the
> entirety of my project, boost, qt, and any other dependencies I have
> before compiling anything? My current understanding is that I would
> need to.

You'd need to scan "your project", at least. Modules provided by
external sources would be assumed already exist. (More accurately,
modules that are not generated by your project are assumed to just
exist. If not, that's just a build error. What would be bad is
mislabeling a module that *is* generated by your project as "external",
because it means your build graph is broken. I could see this happening
if the source that will generate that module is generated.)

If modules are *not* intended to replace #include, then trivial projects
might be able to skip this scanning step under the assumption that all
modules are external. However, I doubt this will hold true even if e.g.
a module corresponds to a library, as many larger projects consist of
multiple libraries and would most likely want to use internal modules.

> My view is that – regardless of modules – we (the C++ community) do
> need to have a common way to describe components (e.g. where
> installed build artefacts go, etc.)

http://wg21.link/p1313 :-).

-- 
Matthew