<html 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:0cm;
        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:#954F72;
        text-decoration:underline;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
        {page:WordSection1;}
--></style></head><body lang=HU link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>I agree with the vast majority of Lazăr, that encoding things twice is redundant and error prone, and also CMake is not something I would like to live with in the long run. I do have to give meson and build2 a spin some time. (I have already expressed my ideas of an extensible, tool and language aware build system, so I won’t repeat.) However, tooling cannot leave behind legacy codebases, so they do have to deal with all sorts of layout and coding style. The approach taken by akro is nice, but then I’d ask: why not go all the way and mandate „#pragma lib” as done by MSVC? Why must the library (filename) be implicit when the interface header (filename) is explicit? Converting existing code to using any other style than they are using today will cause immense friction and fragmantation. CMake succeeded because it caters to most use cases.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Having that said, with the second layer of dependency tracking and compilation is no pain if a tool takes care of it. If you use Visual Studio, you just add the file in Solution Explorer and the MSBuild .vcxproj file is automatically updated to compile it. CLion can do something very similar with CMake scripts even.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>TL;DR:</b> I don’t care that build definitions exist if I’m not the one who authors them.</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>Feladó: </b><a href="mailto:boris@codesynthesis.com">Boris Kolpackov</a><br><b>Elküldve: </b>2019. február 1., péntek 7:58<br><b>Címzett: </b><a href="mailto:tooling@open-std.org">WG21 Tooling Study Group SG15</a><br><b>Tárgy: </b>Re: [Tooling] Modules</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Dorin Lazar <dorin.lazar@gmail.com> writes:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> [...] you basically specify an „entry point”, and then assumes that if</p><p class=MsoNormal>> you #include "utils/string_utils.h" you might have a "utils/string_utils.cpp"</p><p class=MsoNormal>> to contain the code described in the "utils/string_utils.h".</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Another approach with the same end-result is globbing (potentially</p><p class=MsoNormal>recursive). Neither covers everything 100% (auto-generated source</p><p class=MsoNormal>code is a notable issue) but I agree, not having to touch your</p><p class=MsoNormal>buildfiles every time you add a source file to a project has been</p><p class=MsoNormal>liberating.</p><p class=MsoNormal>_______________________________________________</p><p class=MsoNormal>Tooling mailing list</p><p class=MsoNormal>Tooling@isocpp.open-std.org</p><p class=MsoNormal>http://www.open-std.org/mailman/listinfo/tooling</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>