C++ Logo


Advanced search

Re: [Tooling] Package Dependency Manager (PDM) and Build System Guidelines

From: Rene Rivera <grafikrobot_at_[hidden]>
Date: Sat, 17 Mar 2018 20:57:12 -0500
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

Received on 2018-03-18 02:57:15