<div dir="ltr">I *highly* endorse the approach of having a tool extract and maintain the build information. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 1, 2019 at 3:04 PM Peter Bindels &lt;<a href="mailto:dascandy@gmail.com">dascandy@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><span class="gmail-m_-7923672990431182195gmail-im">
&gt; Titus Winters &lt;<a href="mailto:titus@google.com" target="_blank">titus@google.com</a>&gt; writes:<br>
&gt;<br>
&gt;&gt; We&#39;ve been doing explicit statements of the dependency chain for our<br>
&gt;&gt; codebase for almost 20 years, and I&#39;ve literally never heard a new hire (or<br>
&gt;&gt; anyone else) say it is a &quot;huge&quot; burden.<br></span></div><div dir="ltr"><br></div><div dir="ltr">Bjarne Stroustrup writes:<br>
&gt; Seriously, having manual dependency specification is inherently <br>
&gt; error-prone (independent double specification always is), as well as <br>
&gt; extra work. The fact that it is manageable for someone somewhere doesn&#39;t <br>
&gt; change that. I suspect its a skills, productivity, and scaling issue.</div><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 1 Feb 2019 at 18:22, Bill Hoffman &lt;<a href="mailto:bill.hoffman@kitware.com" target="_blank">bill.hoffman@kitware.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Except for toy projects, you need to tell the compiler what files will <br>
go into which libraries and executables. </blockquote><div><br></div><div>At work we&#39;re using an automated tool to create these things automatically, and it&#39;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&#39;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.</div><div><br></div><div>The accuracy of our autogenerated files is 100%, and if it gets it wrong we&#39;ve got an open challenge to the whole company to tell us. We&#39;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&#39;d just added or removed.<br></div><div><br></div><div>I&#39;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&#39;t run it.</div><div><br></div><div>As an extension to this, I&#39;ve created Evoke that does the same basic derivation, but then does the whole build system part too. I&#39;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&#39;ve tried it on it works. Full stop.<br></div><div> <div dir="ltr" class="gmail_attr">On Fri, 1 Feb 2019 at 18:22, Bill Hoffman &lt;<a href="mailto:bill.hoffman@kitware.com" target="_blank">bill.hoffman@kitware.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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. </blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_attr">On Fri, 1 Feb 2019 at 18:22, Bill Hoffman &lt;<a href="mailto:bill.hoffman@kitware.com" target="_blank">bill.hoffman@kitware.com</a>&gt; wrote:<br></div>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.</blockquote><div><br></div><div>Disagreed. I showed why not at CppCon 2018.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_attr">On Fri, 1 Feb 2019 at 18:22, Bill Hoffman &lt;<a href="mailto:bill.hoffman@kitware.com" target="_blank">bill.hoffman@kitware.com</a>&gt; wrote:<br></div>I think it <br>
would be a huge step backwards to ask users to also specify the include <br>
depends and the module depends. </blockquote><div><br></div><div>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*.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_attr">On Fri, 1 Feb 2019 at 18:22, Bill Hoffman &lt;<a href="mailto:bill.hoffman@kitware.com" target="_blank">bill.hoffman@kitware.com</a>&gt; wrote:<br></div>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.<br></blockquote><div><br></div><div>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?</div></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div></div>
_______________________________________________<br>
Tooling mailing list<br>
<a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
</blockquote></div>