On Fri, Mar 16, 2018 at 8:30 AM, Torvald Riegel <triegel_at_[hidden]> wrote:

> On Thu, 2018-03-15 at 22:46 -0500, Rene Rivera wrote:
> > 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.
> >
> > With that in mind I'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:
> >
> > 1. This is actually a solved problem.
>
> You haven't even clearly specified what the problem is, exactly. Nor
> has anyone else posted a clear description to this list. It's easy to
> say "dependency", but in practice this comes in various flavours and is
> affected by how developers want to manage their software and the
> lifecycle and maintenance of it.
>
> The first step should be describing, in detail, what the problems are
> that you actually want to solve, what the target audience is, etc.
>
> > It's been done before (1)
> >
> > 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.
>
> That different paths through the solution space have been implemented
> does not mean that on path (or a small set) are ready to be
> standardized.
>

Yes, all true.


> Open specification (3)
> >
> > 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'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't
> > follow the current model of the standards process to accommodate this
> > flexibility. We need a standards model that allows for new specifications
> > "outside" of the core. There is one group of standards that follows an
> open
> > model we can borrow from, OpenGL. OpenGL'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.
>
> Two points to note here:
> (1) Is an major-update cycle that's shorter than three years actually
> best for consumption by the target audience (and when factoring in
> implementers and their requirements / realities)?
>

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.


> (2) Flexibility needs to have a clear goal. Do you want extensions to
> be non-standard in the sense that we can't get consensus for them, or do
> you rather want to make use of the TS process we already have?
>

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.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net