On 4 October 2016 at 00:16, Rene Rivera <grafikrobot@gmail.com> wrote:

* It attempts to minimize the amount of compiler/toolset knowledge a programmer needs to know to get most things done portably.

* It attempts to minimize the amount of work a programmer does to build variations of the same code.

* It attempts to "bake" the knowledge of tools and systems from experts so that non-experts can use those tools and systems.

* And it attempts to do all that by modeling what a programmer is building instead of how to do that building.

Rene, this to me is exactly while Boost-Build is such a wonderful idea - take for example the current state of cross-platform Mobile development.
The reality facing most small to medium programming houses is "use Xanmarin", for something like game development (or in my case, graphics software development), that just isn't an option.

Despite my very best arguments to the contrary, the company I work for ended up using a third-party framework called Marmalade, (and with no disrespect to the developers of that project intended-) it was an 'effing nightmare! Especially when we ended up needing Bluetooth support.
We are now porting our code to rely entirely on SDL and native C++ implementations - something I advocated in the first place. The problem we are facing at the moment is the same reason my proposals where rejected, there is currently no easy to use build system for C++ mobile development.

So I'm going to forgo reality for a moment, and enter into fantasy.

Imagine if you will, the near future, Windows-8-metro has returned (and assimilated) and Windows-11 entirely uses LCARS interfaces.. as does the latest Visual-studio 17-&-1/5"

On a freshly installed computer I load Visual-studio, I click "New Boost Project" having installed but a single extension, Boost-build downloads and assembles itself in a few moments, I add a blank cpp file, add a 'void Main()' (mostly to annoy my co-workers), then change my build targets - adding Android and Mac-OSX.

I press build, the relevant open-source toolchains are downloaded, installed, and the build begins. A few minutes later, I'm debugging my program on windows, confident it will work as well on Android and OSX - Saving myself (and my company) weeks of hair-pulling chaos compared to the previous methods.

Now, I realize this statement is a HUGE abstraction of the underlying mechanisms, requiring not only a new boost-build, but massive amounts of Visual-studio plugin development and a fair amount of package-management that is beyond the scope of this discussion.

However, it is absolutely possible - given a build system capable of handling it, I have no doubt the package-systems and plugins to make said vision a reality would be very, very close behind (mostly because I would be trying to create them!).

To someone who has never partaken in these kinds of cross-platform developments before, this may seem like a "simple" or "obvious" proposal - however in the current state of development (particularly C++ development) It's just not possible, or realistic.

TL;DR

1. A new Build system should endeavor to be as capable for IDE-development as for terminal-development - Obviously.

2. It's my opinion that such a system should be geared toward solving today's real-world problem with cross-platform development (especially on mobile devices).
3. I'm not suggesting that Build should be a complex mobile-development framework - what I'm suggesting is a build system that can easily be automatically configured, to build (and debug) someone else's mobile-development framework.
4. Debugging - it may seem strange, especially to avid terminal-adb users; however simply building something does not mean one can debug it. Indeed, most developers today literally cannot use a debugger if it is not integrated into an IDE.

A. My apprentice completed a three year programming course at a respected English university, Gaining a Distinction grade (the only person in his class to do so) - He did not know how to use the Debugger built into Visual Studio, He could not read Hexadecimal or Binary, He did not understand the meaning of "Stack Overflow". This is the generation to-which we will hand our creations - as dismal a fortune as that may be.