<div dir="ltr"><div>We have a rather serious problem in our hands. On one hand we have a clamoring of people who want a PDM driven ecosystem for C++. On the other we have those who think this is an impossible task and we should give up now. To both groups I can say that C++ PDMs exist and are growing in popularity and breadth and making something standard from the existing practice is possible. We just have to decide how much should be standard. And the same goes for build systems.<br></div><div><br></div><div>With that in mind I&#39;ve been looking at how we get from where are today and the future many of us want. Here are some guidelines for approaching the problem:</div><div><br></div><div>1. This is actually a solved problem. And as such we need to identify what works and doesn&#39;t from existing solutions.</div><div><br></div><div>2. We should strive for an open implementation model in line with how C++ is currently specified.</div><div><br></div><div>3. It is impossible to specify everything ahead of time as the C++ tool and library landscape changes faster than we can possible write standards for them.</div><div><br></div><div>4. This is the ecosystem we are trying to improve. Hence we need to think of how the solutions fit the overall domain.</div><div><br></div><div>5. This is a placeholder item. This is not a complete list and should grow over time. Please suggest more items :-)</div><div><br></div><div><br></div><div>That&#39;s the TLDR version of the guidelines. Here&#39;s the long version..</div><div><br></div><div>It&#39;s been done before (1)</div><div><br></div><div>We have a variety of existing solution for both PDMs for C++, and other languages (for instance conan and cget). Build systems are numerous, and varied. There are even some systems that combine both.</div><div><br></div><div>Open implementation model (2)</div><div><br></div><div>When we look at other ecosystems we see mostly a &quot;monolithic&quot; model. We see one compiler, one runtime, one PDM, one build system, all integrated to work together. Although this is an attractive model to present users it doesn&#39;t fit the C++ heterogeneous model:</div><div><br></div><div>* We already have a multitude of compilers.</div><div>* That multitude increases the rate of improvement of those compilers, and related tools.</div><div>* We can tailor those compilers to specific use cases while presenting the same language to users.</div><div><br></div><div>We achieved that model by not specifying the implementation of the language. But by instead specifying the &quot;surface&quot; of the language. This same heterogeneous model is what we should follow when consider PDMs and build systems. We should define the &quot;surface&quot; of how PDM and build system implementations operate and communicate within the ecosystem. This is the achievable part.</div><div><br></div><div>Open specification (3)</div><div><br></div><div>The possibilities of the specifics of what a PDM and build system can accomplish is open ended. And as we see from current compiler solutions, and technological innovations, it&#39;s a quickly changing landscape. We need specifications that are flexible enough to grow and adjust faster than the core C++ Language standard has evolved so far. This implies that we can&#39;t follow the current model of the standards process to accommodate this flexibility. We need a standards model that allows for new specifications &quot;outside&quot; of the core. There is one group of standards that follows an open model we can borrow from, OpenGL. OpenGL&#39;s core specifications with added extension specifications allows for quick adaptation to the quickly changing GPU advancements. We can use such a structure to model the changing C++ tool advancements without waiting for the three year cycle.</div><div><br></div><div>Fit what we have and know (4)</div><div><br></div><div>If we have some hope of improving the C++ ecosystem this generation we need to work within the current set of tools we have. Our ecosystem may be unwieldy and downright treacherous at times, but it&#39;s what has worked for us. We need to conceive of specifications that fit CLIs, IDEs and their related checkers, debuggers, build systems, PDMs, distribution mechanism, and all that without closing doors to different and better technologies. It will be a golden era when we can pick and choose our preferred set C++ tools and have them all work together seamlessly (within obvious constraints). For PDMs and build systems this means thinking about not just CLI environments. But IDE, GUI installers, GUI wizards, CI automation, and so on when defining how PDMs and build systems should operate.</div><div><br></div><div><br></div>-- <br><div class="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>