>> 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.

Build system globbing is a very polarizing topic, with some people claiming it's the only way to go, and other people claiming that you should never do it. Regardless of a given tool's preference, there are lots of people in each camp. I'd prefer to not alienate either camp if possible.




> -----Original Message-----
> From: tooling-bounces_at_open-std.org <tooling-bounces_at_open-std.org> On
> Behalf Of Matthew Woehlke
> Sent: Friday, February 1, 2019 9:07 AM
> To: tooling_at_[hidden]
> Subject: Re: [Tooling] Modules
>
> 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__en.wikipedia.org_wiki_Don-2527t-5Frepeat-
> 5Fyourself&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&
> r=y8mub81SfUi-
> UCZRX0Vl1g&m=c2Cv8x8dPrUcLGz0K3gGbuAgwVBcTg2sdqk3L2tNuKY&s=yJ-
> WvlzthOcu9OGBSbZl0cZ_MXICjq85Ex6bQ92ps3U&e=)
>
> --
> Matthew
> _______________________________________________
> Tooling mailing list
> Tooling_at_isocpp.open-std.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.open-
> 2Dstd.org_mailman_listinfo_tooling&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6
> YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-
> UCZRX0Vl1g&m=c2Cv8x8dPrUcLGz0K3gGbuAgwVBcTg2sdqk3L2tNuKY&s=1LY
> Ew-Au949685K01ldkaQL5SpNPHSUoHB6DbKg78X0&e=