We've been doing explicit statements of the dependency chain for our
codebase for almost 20 years, and I've literally never heard a new hire (or
anyone else) say it is a "huge" burden.

To be sure, artifacts depend on libraries, but every individual library
fully expresses what it is composed of, and the build system itself ensures
that a change to build flags or header contents.

On Thu, Jan 31, 2019 at 6:23 PM Corentin <corentin.jabot_at_[hidden]> wrote:

> 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]> 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] <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]>
>> *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]
>> http://www.open-std.org/mailman/listinfo/tooling
>>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>