<div dir="ltr">Here&#39;s a concrete example of why the preprocessor matters deeply in this discussion.<div><br></div><div>If we build from source, we have to handle the (all too common) situation where a given library has an arbitrary set of build inputs (-D flags, compiler flags, etc).  If those aren&#39;t compatible, that&#39;ll be a problem.</div><div><br></div><div>If we force them to all be the same, then we have to worry about providing a mechanism to specify which flags (from an unbounded list) are required / compatible with a given library.  That&#39;s hard to extract from source.</div><div><br></div><div>If we instead allow each library to be built from different compiler invocations, we risk ODR.  Keep in mind that even something as simple as an assert() in a header is an ODR violation if we don&#39;t enforce consistent build flags: building that header with one definition of NDEBUG in one TU results in a different definition than one built without NDEBUG in another TU.  </div><div><br></div><div>In all honesty, the preprocessor and consistent build invocation is possibly the hard part.  If we come to agreement on those points, relying on existing package management solutions probably suffices.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 16, 2018 at 11:06 AM Rene Rivera &lt;<a href="mailto:grafikrobot@gmail.com">grafikrobot@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 16, 2018 at 4:59 AM, Corentin <span dir="ltr">&lt;<a href="mailto:corentin.jabot@gmail.com" target="_blank">corentin.jabot@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I will be a bit cynical for a bit.</div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Constructive cynicism is welcome ;-) </div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>There isn&#39;t anything in C++ as a language preventing us from having a good PDM.</div><div>Of course, the preprocessor completely undermines that observation, but the preprocessor is not part of C++. </div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>[cut] </div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>And that&#39; s why we may fail to come up with a good dependency manager.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I don&#39;t see the correlation between the preprocessor and the package manager. Can you explain how the PP technically &quot;undermines&quot; the implementation of a PDM?</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Not just because of the preprocessor, but because having a universal tool will require strong constraints on what a project can do in its build system.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>That&#39;s clearly not true as we can see with conan, vcpkg,  spack, nix, and more, that manage to deal with all the variations of build systems. Albeit they do it in a brute force manner. But that why we are here discussing how to standardize the interactions between PDMs and build systems. What restrictions are you contemplating?</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>We need to take away freedom. </div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>We need to limit the number of compiler flags a library can use and impose to others, we need to limit the number of ways a given source file can be expressed.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Why?</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>It&#39;s the only way to have a system of manageable complexity with a manageable numbers of unsolvable dependencies.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>How? Current PDMs and build systems manage the complexity reasonably well already. So I&#39;m failing to see how you think it&#39;s unmanageable.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>And we will shy away from that.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I surmise that you can only speak for yourself in that statement. As I personally don&#39;t tend to shy away from complexities. In complexity I see solutions.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The only way to have a large number of libraries that one can include in their projects from the same place, with the same straight forward workflow is to have those libraries play by the same rules.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Yes, we do need some level of common rules. But we are now getting into the solutions ;-) I have a proposal I&#39;m working to specify such a common set of rules. But I&#39;ll leave that for a subsequent post.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Other tools in other language impose those rules, they have limited abilities. Yet they are powerful enough that everybody use those tool with great effects.</div><div>But those tools were there from the start, so, the code was made with these tools in mind.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>C++ has rules.. The entirety of the standard is a, somewhat comprehensive, ruleset.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>There is something to be said for monolithic ecosystems.<br></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>True.. monolithic ecosystem make it easier for if you are starting from nothing. But they also unnecessarily lock you in by the choices that you make to obtain that ease of implementation. </div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>From a user perspective, to install the package `foo` maybe they need to type a command or maybe the build system will do that for them. </div><div>If the command does not exist on the system, we failed.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Thinking that they type a command is limiting ;-) They could alternative be choosing a menu item in their IDE that lets them search through a database of packages with keywords and sort by popularity. Or they could just use &quot;#include &lt;xyz.hpp&gt;&quot;, or import a module, and the build system or IDE will automatically search for a package that has that dependency and ask you if it can install that dependency. And I can think of many more variations of that.. Hence, there are many ways we *don&#39;t* fail.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> If the correct command is not identical to the one indicated in the documentation of the project, we failed. If that documentation is longer than exactly one line in most cases, we failed, if the build system does not support it, we failed.</div><div>(imagine : vcpkg get bar/foo / xcode-cpp-fetch  <a href="http://baz.com/bar:foo" target="_blank">baz.com/bar:foo</a> / iso-get --from <a href="http://baz.com" target="_blank">baz.com</a> --org bar --import=export --package foo@version:&lt;auto last&gt; ) </div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Any move towards adding more non-failure routes the better we are from the current state of the ecosystem. And, yes, we will not be able to remove failure. But C++ has never been about preventing you from shooting yourself in the foot. </div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>And, if there is anyway `foo` can resolve to different projects, we failed.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Cynical indeed ;-)</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Monolithic systems also exist because there is a need for &quot;dependency foo&quot; to have exactly one meaning.</div><div><br></div><div>Doing a dependency manager is hard but as you said, it&#39;s a solved problem. Doing one able to handle the existing code may not be. It&#39;s harder. Maybe not solvable. Is it worth trying ? I don&#39;t know.</div><div>Like Titus said, people need too learn what a well behaved dependency is.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>We also need to define what kinds of dependencies we are willing to manager.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>But if we decide to have an idealistic approach, will people adopt that new tool/protocol/standard ? Nobody like dealing with build systems, and whatever crappy CMake scripts they have today &quot;works&quot; - well, they think they do.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The hope is that: (a) vendors/maintainers would want to participate in the common ecosystem and (b) that the cost of support is minimal and/or worth it. But since this is something that users clearly want I&#39;m fairly certain we can get that support.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Rust, for example did not endure 30 years of complete wild west jungle mess before offering those tools, that&#39;s the difference.</div><div>Likewise, I&#39;m doubtful that anyone in those communities would be successful in offering an alternative solution to their idiomatic tools.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I don&#39;t know if other communities can&#39;t or wont. And I don&#39;t think it&#39;s worth our time to fathom their future. We have our own future to worry about.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>So, really C++ is not the major issue.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Oh good!</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The major issue is the amount of C++ libraries out there all with overly complex, non portable build scripts, the unwillingness of their authors to support something new or their lack of resources to do so. </div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Funny thing.. It turns out conan is more popular than vcpkg. Yet conan has less packages available. I can&#39;t entirely say why that is, but I suspect that one aspect is the quality of the libraries available in conan.</span><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>And a package manager without libraries is a bit pointless, isn&#39;t it ? Chicken egg problem and all.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>It&#39;s technically not possible for a package manager to exist without libraries. As they are required for the implementation. Even if it&#39;s a small number. After that it&#39;s a matter of iterative growth. </div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> (I also tend to think that the publication of a given project in any kind of public repository is best left to their author, rather than a third party packager as that weakens the trust in the dependencies)</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Trust it earned.. And it&#39;s possible for users to trust third party packaging. Since we already have many examples of that level of trust. </div></div></div></div><div dir="ltr"><div class="gmail_extra"><br clear="all"><div><br></div>-- <br><div class="m_3167229520030210720m_5684522146970368172m_2830207865132825014m_-3052244443273927835gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">-- Rene Rivera<br>-- Grafik - Don&#39;t Assume Anything<br>-- Robot Dreams - <a href="http://robot-dreams.net/" target="_blank">http://robot-dreams.net</a><br><br></div></div></div></div>
</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>