<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 16, 2018 at 8:30 AM, Torvald Riegel <span dir="ltr">&lt;<a href="mailto:triegel@redhat.com" target="_blank">triegel@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 2018-03-15 at 22:46 -0500, Rene Rivera wrote:<br>
&gt; We have a rather serious problem in our hands. On one hand we have a<br>
&gt; clamoring of people who want a PDM driven ecosystem for C++. On the other<br>
&gt; we have those who think this is an impossible task and we should give up<br>
&gt; now. To both groups I can say that C++ PDMs exist and are growing in<br>
&gt; popularity and breadth and making something standard from the existing<br>
&gt; practice is possible. We just have to decide how much should be standard.<br>
&gt; And the same goes for build systems.<br>
&gt;<br>
&gt; With that in mind I&#39;ve been looking at how we get from where are today and<br>
&gt; the future many of us want. Here are some guidelines for approaching the<br>
&gt; problem:<br>
&gt;<br>
&gt; 1. This is actually a solved problem.<br>
<br>
</span>You haven&#39;t even clearly specified what the problem is, exactly.  Nor<br>
has anyone else posted a clear description to this list.  It&#39;s easy to<br>
say &quot;dependency&quot;, but in practice this comes in various flavours and is<br>
affected by how developers want to manage their software and the<br>
lifecycle and maintenance of it.<br>
<br>
The first step should be describing, in detail, what the problems are<br>
that you actually want to solve, what the target audience is, etc.<br>
<span class=""><br>
&gt; It&#39;s been done before (1)<br>
&gt;<br>
&gt; We have a variety of existing solution for both PDMs for C++, and other<br>
&gt; languages (for instance conan and cget). Build systems are numerous, and<br>
&gt; varied. There are even some systems that combine both.<br>
<br>
</span>That different paths through the solution space have been implemented<br>
does not mean that on path (or a small set) are ready to be<br>
standardized.<br></blockquote><div><br></div><div>Yes, all true.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
&gt; Open specification (3)<br>
&gt;<br>
&gt; The possibilities of the specifics of what a PDM and build system can<br>
&gt; accomplish is open ended. And as we see from current compiler solutions,<br>
&gt; and technological innovations, it&#39;s a quickly changing landscape. We need<br>
&gt; specifications that are flexible enough to grow and adjust faster than the<br>
&gt; core C++ Language standard has evolved so far. This implies that we can&#39;t<br>
&gt; follow the current model of the standards process to accommodate this<br>
&gt; flexibility. We need a standards model that allows for new specifications<br>
&gt; &quot;outside&quot; of the core. There is one group of standards that follows an open<br>
&gt; model we can borrow from, OpenGL. OpenGL&#39;s core specifications with added<br>
&gt; extension specifications allows for quick adaptation to the quickly<br>
&gt; changing GPU advancements. We can use such a structure to model the<br>
&gt; changing C++ tool advancements without waiting for the three year cycle.<br>
<br>
</span>Two points to note here:<br>
(1) Is an major-update cycle that&#39;s shorter than three years actually<br>
best for consumption by the target audience (and when factoring in<br>
implementers and their requirements / realities)?<br></blockquote><div><br></div><div>Since compilers revision at a considerably faster rate than three years.. And we will need to account for changes in those compilers.. Hence we need to cycle faster than three years.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(2) Flexibility needs to have a clear goal.  Do you want extensions to<br>
be non-standard in the sense that we can&#39;t get consensus for them, or do<br>
you rather want to make use of the TS process we already have?<br></blockquote><div><br></div><div>Right.. The flexibility we need will come out as we work out the various parts of the problem. But at least for compiler options; which is my first task; we need some inherent room for vendor specific options that are documented and published. The TS process might be sufficient.. We&#39;d have to evaluate how it fits.</div><div><br></div></div><div><br></div>-- <br><div class="gmail_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>