Re: [Boost-build] Son of b2 - suggestions

Subject: Re: [Boost-build] Son of b2 - suggestions
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-10-29 14:14:22

Am 29.10.2016 um 13:57 schrieb Paul A. Bristow:
> A few suggestions as you are getting closer to prototyping.
I do agree with most of your suggestions, but not with all; but overall, 
that makes a lot of sense.
> 1  Assume nothing - absolutely nothing.  Do not assume that users are familiar with command lines, most will not be.  Command line
> stuff is regarded as last-millenium. Do not assume that what is obvious to you is obvious to all.  Assumption is the mother of all
> foul-ups!  Learn from the failures of b2 (see endless cries for help on StackOverflow and Boost if you doubt this harsh view).
> Update documentation from each help request.  Ask why the user is confused and how he should have found the answer himself.
I completely disagree with the command-line stuff. It's hard enough to 
get a command-line tool right, and that's what this should be focused 
on. We already discussed an Interface to IDEs etc. but this should not 
be our main concern. Also: I don't think Consoles going anywhere. With 
the popularity of tools like git, it's coming back, if anything. A build 
system basically calls a set of commands, so it's hard to avoid the topic.
> 2  Be very reluctant to require more tools, like Python.  Every extra tool that you add will reduce the number of people who will
> use it.  Half of your prospective users have never heard of Python, and barely know of Unix.
I don't think so. I think the people you're thinking about are the 
IDE-Buildsystem users, and if that does it for them, they shouldn't 
switch. It's more a case of, how portable the tool is. Python has 
extremely widespread support, so I don't see an issue there. Java or 
.net would be insanely bad choices.
> 4  Minimise the concepts.  The difference between options, commands, abbreviations and rules can be confusing. .  For example, stage
> and install cause endless confusion to users.
I'd say that depends: keep as little concepts as reasonable would be 
fitting. Force them to be few is the wrong approach, that's what Java 
tried with making everything OO.
> 8  Too many tools are being too clever trying to make things 'just work' -  except that they often 'just don't' :-(
That's actually the reason I'm interested in b3; there are too many 
build systems which think they're clever and super-easy (like 
mesonbuild) but then fail me as soon as I try something they haven't 
thought of.
> 14 When there are variants for Windows and *nix, assume Windows, and assume Windows users are less smart.
Or have a too small SSD, cannot find a driver for the notebook-wlan-card 
for debian and want to occasionaly play a game.