<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.gmail-m-7923672990431182195gmail-im
        {mso-style-name:gmail-m_-7923672990431182195gmail-im;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">+1.<o:p></o:p></p>
<p class="MsoNormal">I suggested same on the call yesterday<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> tooling-bounces@open-std.org <tooling-bounces@open-std.org>
<b>On Behalf Of </b>Titus Winters<br>
<b>Sent:</b> Friday, February 1, 2019 12:07 PM<br>
<b>To:</b> WG21 Tooling Study Group SG15 <tooling@open-std.org><br>
<b>Subject:</b> Re: [Tooling] Modules<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I *highly* endorse the approach of having a tool extract and maintain the build information. <o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Feb 1, 2019 at 3:04 PM Peter Bindels <<a href="mailto:dascandy@gmail.com">dascandy@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span class="gmail-m-7923672990431182195gmail-im">> Titus Winters <<a href="mailto:titus@google.com" target="_blank">titus@google.com</a>> writes:</span><br>
<span class="gmail-m-7923672990431182195gmail-im">></span><br>
<span class="gmail-m-7923672990431182195gmail-im">>> We've been doing explicit statements of the dependency chain for our</span><br>
<span class="gmail-m-7923672990431182195gmail-im">>> codebase for almost 20 years, and I've literally never heard a new hire (or</span><br>
<span class="gmail-m-7923672990431182195gmail-im">>> anyone else) say it is a "huge" burden.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Bjarne Stroustrup writes:<br>
> Seriously, having manual dependency specification is inherently <br>
> error-prone (independent double specification always is), as well as <br>
> extra work. The fact that it is manageable for someone somewhere doesn't <br>
> change that. I suspect its a skills, productivity, and scaling issue.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">On Fri, 1 Feb 2019 at 18:22, Bill Hoffman <<a href="mailto:bill.hoffman@kitware.com" target="_blank">bill.hoffman@kitware.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Except for toy projects, you need to tell the compiler what files will
<br>
go into which libraries and executables. <o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">At work we're using an automated tool to create these things automatically, and it's proven to be both much more maintainable and more accurate at tracking dependencies and constituent files than any developer was so far - both in removing
dependencies when the last include was removed, and in adding new ones when a new include was added. This is on a large project, 400+ developers working on 1000+ components. In this project we're autogenerating about 79% of all CMakeFiles, with the remaining
21% being mostly platform dependent things, other language integration and odd bits of generated sources requiring uncommon build steps.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The accuracy of our autogenerated files is 100%, and if it gets it wrong we've got an open challenge to the whole company to tell us. We've had 30-ish people try it, and one found an actual bug that we subsequently solved. 29 were wrong
about their dependencies that they'd just added or removed.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm also using it on a different project, where 100% of the build files are autogenerated. This works fine - in fact, the only time the build breaks on a dependency issue is if you don't run it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As an extension to this, I've created Evoke that does the same basic derivation, but then does the whole build system part too. I've not yet used it widely enough - in part because I try not to convince coworkers to switch to a new tool
every few months - but on the targets I've tried it on it works. Full stop.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal">On Fri, 1 Feb 2019 at 18:22, Bill Hoffman <<a href="mailto:bill.hoffman@kitware.com" target="_blank">bill.hoffman@kitware.com</a>> wrote:<o:p></o:p></p>
</div>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">You could point a compiler at a <br>
file with main in it and have it figure out everything that is used by <br>
that main and build a single executable. However, breaking code down <br>
into libraries and deciding if the libraries are shared, static, <br>
dynamically loaded is something the developer is going to need to <br>
control. <o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I doubt that. Shared libraries as a generic thing are a choice that needs a whole lot more thought than nearly all developers are putting into these choices; static by default is the only sane option.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">On Fri, 1 Feb 2019 at 18:22, Bill Hoffman <<a href="mailto:bill.hoffman@kitware.com" target="_blank">bill.hoffman@kitware.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal">If you use an IDE it is done by drag and drop with a graphical
<br>
interface. If you use CMake it is done by listing the sources you want <br>
for each library or executable in the CMake file. Basically you need to <br>
partition the set of source files into a set of products from the <br>
compiler. Any build tool or IDE is going to have to do this.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Disagreed. I showed why not at CppCon 2018.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">On Fri, 1 Feb 2019 at 18:22, Bill Hoffman <<a href="mailto:bill.hoffman@kitware.com" target="_blank">bill.hoffman@kitware.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal">I think it <br>
would be a huge step backwards to ask users to also specify the include <br>
depends and the module depends. <o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That is true though; we need to be careful for in particular existing build systems like shell scripts, makefiles and cmakefiles that we make sure these builds are unbroken - suboptimal is fine, but they should *work*.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">On Fri, 1 Feb 2019 at 18:22, Bill Hoffman <<a href="mailto:bill.hoffman@kitware.com" target="_blank">bill.hoffman@kitware.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal">In CMake we have had Fortran working for <br>
years now. You list all the Fortran files you want in a product and <br>
CMake parses the Fortran to figure out the build order defined by the <br>
producers and consumers of modules in the set of Fortran files it was <br>
given. In practice with Fortran users having to figure out the correct <br>
order of module builds resulted in people running make over and over <br>
until all the modules were produced and the code compiled unless they <br>
use a tool like CMake.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Do you wish the same upon C++, where parsing the code requires a full preprocessor and in many cases may not even reveal that a file is never built, built 4x with different options, or only on some platforms exports a given module? On sundays?<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Tooling mailing list<br>
<a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7C32d8ac47e86b44d25fb908d68880e104%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636846484449823380&sdata=%2BYirt4MvJjJDWQpaQnz%2BHI%2Bnw4a8%2BIM3tWJn3joGBrk%3D&reserved=0" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>