I think a lot of confusion is coming from people making implicit assumptions. Ville's QMake scenario is closer to what I expect with modules than anything else conjured up and then shown a burden I have seen so far.

-- Gaby


-------- Original message --------
From: Corentin <corentin.jabot_at_[hidden]>
Date: 1/31/19 3:23 PM (GMT-08:00)
To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
Subject: Re: [Tooling] Modules

To add to that,
we assume there are many more modules (TU) than libraries, and as such manually specifying dependencies within source files will be deemed a huge maintenance burden by a lot of people
(a reason why header only libraries are popular) and would make build scripts and build systems even more complicated than they are, when we should probably strive to make them simpler.

To my knowledge, no other language requires to explicitly specify dependencies at that level of granularity - artifacts depends on packages/libraries, not individual files ( ie: module)


On Thu, 31 Jan 2019 at 23:58 Ben Craig <ben.craig_at_[hidden]<mailto:ben.craig_at_[hidden]>> wrote:
“If my build system has already encoded all of my dependencies in a secondary layer (my build files), do I care about any of these concerns? “
Channeling Tom Honermann, but yes, your other tools care. 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.

“I'm reasonably sure from past experience is that a proper modular and parallized build requires that secondary layer. (To say nothing of performance concerns: rescanning constantly is a waste of computation.)”
It may be the case that such concessions are necessary. However, I will argue that a significant portion of C++ projects don’t currently specify in their build files that foo.cpp depends on foo.h, boost/spirit.h, and the other hundred headers that boost/spirit.h drags in. 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. 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.

From: tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]> <tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]>> On Behalf Of Titus Winters
Sent: Thursday, January 31, 2019 1:28 PM
To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>>
Subject: [Tooling] Modules

(Sorry for having to drop off, scheduling conflict.)

To clarify a little and ensure I understand properly:

If my build system has already encoded all of my dependencies in a secondary layer (my build files), do I care about any of these concerns?

Or, put another way: is the current debate about "I want the build to be synthesized at compile-invocation time from source, without that secondary layer"?

I'm reasonably sure from past experience is that a proper modular and parallized build requires that secondary layer. (To say nothing of performance concerns: rescanning constantly is a waste of computation.)

Or am I misunderstanding?
_______________________________________________
Tooling mailing list
Tooling_at_[hidden]<mailto:Tooling_at_[hidden]>
http://www.open-std.org/mailman/listinfo/tooling<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7Ca5d7c2ae978a4aa41e4a08d687d32cde%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636845738394561018&sdata=NFJczLgRJcm8zNnUU5OAvjQzz5wHrHzmZIxMjf2uBGo%3D&reserved=0>