<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"><<a href="mailto:triegel@redhat.com" target="_blank">triegel@redhat.com</a>></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>
> We have a rather serious problem in our hands. On one hand we have a<br>
> clamoring of people who want a PDM driven ecosystem for C++. On the other<br>
> we have those who think this is an impossible task and we should give up<br>
> now. To both groups I can say that C++ PDMs exist and are growing in<br>
> popularity and breadth and making something standard from the existing<br>
> practice is possible. We just have to decide how much should be standard.<br>
> And the same goes for build systems.<br>
><br>
> With that in mind I've been looking at how we get from where are today and<br>
> the future many of us want. Here are some guidelines for approaching the<br>
> problem:<br>
><br>
> 1. This is actually a solved problem.<br>
<br>
</span>You haven't even clearly specified what the problem is, exactly. Nor<br>
has anyone else posted a clear description to this list. It's easy to<br>
say "dependency", 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>
> It's been done before (1)<br>
><br>
> We have a variety of existing solution for both PDMs for C++, and other<br>
> languages (for instance conan and cget). Build systems are numerous, and<br>
> 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="">
> Open specification (3)<br>
><br>
> The possibilities of the specifics of what a PDM and build system can<br>
> accomplish is open ended. And as we see from current compiler solutions,<br>
> and technological innovations, it's a quickly changing landscape. We need<br>
> specifications that are flexible enough to grow and adjust faster than the<br>
> core C++ Language standard has evolved so far. This implies that we can't<br>
> follow the current model of the standards process to accommodate this<br>
> flexibility. We need a standards model that allows for new specifications<br>
> "outside" of the core. There is one group of standards that follows an open<br>
> model we can borrow from, OpenGL. OpenGL's core specifications with added<br>
> extension specifications allows for quick adaptation to the quickly<br>
> changing GPU advancements. We can use such a structure to model the<br>
> 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'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'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'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'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>