<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 16, 2018 at 4:59 AM, Corentin <span dir="ltr"><<a href="mailto:corentin.jabot@gmail.com" target="_blank">corentin.jabot@gmail.com</a>></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>Constructive cynicism is welcome ;-) </div><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'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>[cut] </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>And that' s why we may fail to come up with a good dependency manager.</div></div></blockquote><div><br></div><div>I don't see the correlation between the preprocessor and the package manager. Can you explain how the PP technically "undermines" the implementation of a PDM?</div><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>That'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><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>Why?</div><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'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>How? Current PDMs and build systems manage the complexity reasonably well already. So I'm failing to see how you think it's unmanageable.</div><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>I surmise that you can only speak for yourself in that statement. As I personally don't tend to shy away from complexities. In complexity I see solutions.</div><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>Yes, we do need some level of common rules. But we are now getting into the solutions ;-) I have a proposal I'm working to specify such a common set of rules. But I'll leave that for a subsequent post.</div><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>C++ has rules.. The entirety of the standard is a, somewhat comprehensive, ruleset.</div><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>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><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>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 "#include <xyz.hpp>", 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't* fail.</div><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:<auto last> ) </div></div></blockquote><div><br></div><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><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>Cynical indeed ;-)</div><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 "dependency foo" to have exactly one meaning.</div><div><br></div><div>Doing a dependency manager is hard but as you said, it's a solved problem. Doing one able to handle the existing code may not be. It's harder. Maybe not solvable. Is it worth trying ? I don't know.</div><div>Like Titus said, people need too learn what a well behaved dependency is.</div></div></blockquote><div><br></div><div>We also need to define what kinds of dependencies we are willing to manager.</div><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 "works" - well, they think they do.</div></div></blockquote><div><br></div><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'm fairly certain we can get that support.</div><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's the difference.</div><div>Likewise, I'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>I don't know if other communities can't or wont. And I don't think it's worth our time to fathom their future. We have our own future to worry about.</div><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>Oh good!</div><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><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'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><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't it ? Chicken egg problem and all.</div></div></blockquote><div><br></div><div>It's technically not possible for a package manager to exist without libraries. As they are required for the implementation. Even if it's a small number. After that it's a matter of iterative growth. </div><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>Trust it earned.. And it's possible for users to trust third party packaging. Since we already have many examples of that level of trust. </div></div><br clear="all"><div><br></div>-- <br><div class="m_5684522146970368172m_2830207865132825014m_-3052244443273927835gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">-- Rene Rivera<br>-- Grafik - Don'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>