Yes, I'd love some user stories.

As an app developer, I'd like to use Boost.MultiIndex‎ (header only) in this windows (MSVC) app.

As an app developer, I'd like to use Boost‎.Signals (lib) in this cross platform desktop app.

As a library developer, I'd like to use Boost.Python (ver 1.42, not latest) in this library that I distribute for my community of developers doing cross compilation onto Nintendo Gameboy and IoT devices.

(yes, you should be imagining brain... large brain... exploding brain images)

Etc (obviously not just boost, that's just the ones I know. And user stories should focus on one feature (ie versioning) per story, not 10 mixed together)



Sent from my BlackBerry portable Babbage Device
  Original Message
From: Torvald Riegel
Sent: Friday, March 16, 2018 9:39 AM
To: WG21 Tooling Study Group SG15
Reply To: WG21 Tooling Study Group SG15
Subject: Re: [Tooling] Package Dependency Manager (PDM) and Build System Guidelines

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.

> 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)?
(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?


_______________________________________________
Tooling mailing list
Tooling_at_[hidden]
http://www.open-std.org/mailman/listinfo/tooling