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. And as such we need to identify what
works and doesn't from existing solutions.

2. We should strive for an open implementation model in line with how C++
is currently specified.

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.

4. This is the ecosystem we are trying to improve. Hence we need to think
of how the solutions fit the overall domain.

5. This is a placeholder item. This is not a complete list and should grow
over time. Please suggest more items :-)


That's the TLDR version of the guidelines. Here's the long version..

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.

Open implementation model (2)

When we look at other ecosystems we see mostly a "monolithic" 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't fit the C++ heterogeneous model:

* We already have a multitude of compilers.
* That multitude increases the rate of improvement of those compilers, and
related tools.
* We can tailor those compilers to specific use cases while presenting the
same language to users.

We achieved that model by not specifying the implementation of the
language. But by instead specifying the "surface" of the language. This
same heterogeneous model is what we should follow when consider PDMs and
build systems. We should define the "surface" of how PDM and build system
implementations operate and communicate within the ecosystem. This is the
achievable part.

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.

Fit what we have and know (4)

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'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.

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