• We're certainly aiming to get to a world where that secondary build graph layer is machine-managed and generated from source

Same here.

We (collectively) can’t improve our software engineering when are resistant to change.

-- Gaby

From: tooling-bounces@open-std.org <tooling-bounces@open-std.org> On Behalf Of Titus Winters
Sent: Friday, February 1, 2019 6:26 AM
To: WG21 Tooling Study Group SG15 <tooling@open-std.org>
Subject: Re: [Tooling] Modules

I mean, that's fair. :) We're certainly aiming to get to a world where that secondary build graph layer is machine-managed and generated from source. 

On Fri, Feb 1, 2019 at 9:24 AM Bjarne Stroustrup <bjarne@stroustrup.com> wrote:

On 2/1/2019 9:20 AM, Boris Kolpackov wrote:
> Titus Winters <titus@google.com> writes:
>
>> 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.
> The question is to what degree. I am sure you don't require new
> hires to manually specify for each translation unit dependencies
> on headers it includes, transitively?
>
> But that would sure make for a nice hazing ritual.

:-)


Seriously, having manual dependency specification is inherently
error-prone (independent double specification always is), as well as
extra work. The fact that it is manageable for someone somewhere doesn't
change that. I suspect its a skills, productivity, and scaling issue.

> _______________________________________________
> Tooling mailing list
> Tooling@isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/tooling
_______________________________________________
Tooling mailing list
Tooling@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/tooling