Re: [Boost-build] The future of B2?

Subject: Re: [Boost-build] The future of B2?
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2016-10-06 10:23:09

Le 27/09/16 à 02:32, Rene Rivera a écrit :
> Recently I've been doing some cmake, yes I said cmake, for work. And
> this recent experience, and a quick survey of other current build
> systems, has convinced me that there's still nothing like b2. And by
> that I mean nothing that solves the same set of problems with a good set
> of abstractions. Although there are one or two that are moving in our
> direction. But alas, b2 is not widely used. And I can name many reasons
> as to why that might be. But I'd rather discuss where I want b2 to be in
> the future. And hopefully get us moving in a direction that will make b2
> widely used.
>
> Let me start with something rather simple sounding.. What I want to be
> able to do with b2 in my day to day work & play-work (note that this is
> a royal "I" as I'm projecting what others have expressed over the years):
>
> * I want to be able to launch my IDE of choice and be able to build,
> debug, analyze, deploy, etc with b2 as my build system.. And to do that
> without the need to look at a command line.
>
> * I want to be able to use my choice of library package manager and be
> able to consume packages directly in b2.
>
> * I want to be able to use b2 to produce, i.e. specify, build, and
> deploy packages for my choice of package manager entirely in b2.
>
> * I want to be able to use my IDE of choice to configure all aspects of
> my b2 based project with zero or minimal reading of documentation.. And
> especially zero reading of b2 code!
>
> * I want to be able to use current language features as soon as they are
> available, or shortly thereafter, without having to did into toolset
> command flags.
>
> * I want to be able to easily consume and produce b2 extensions.. It
> should be possible for me to browse on-line a collection of extensions
> and directly use them in my project. It should be possible to write my
> own extension and publish it for others to use.
>
> * I want to be able to consult the documentation and quickly find an
> answer for what I need to do with steps to follow. Preferably needing to
> only read *one* screen full of information.
>
> * I want to be able to manage my poly-language projects uniformly with b2.
>
> And I'm putting this one last intentionally..
>
> * I want all that to perform as expediently as possible when I hit the
> build (or whatever button) in my IDE.
>
> By no means is that the end of my possible wish list, but I'll stop
> there for the moment. But now for the really important part.. Do you
> agree that the above are features we should strive, and plan for? Do you
> have features that you think we should strive for in addition to, or
> instead of the above?
>
> And the really hard question.. What of the current b2 implementation,
> design, ecosystem, is getting in the way of reaching the above wishes?
> And if you dare.. What should we change to move forward?
>
> ~~
>
> PS. Feel free to educate me as to the state of the Python port, deamon
> support, and anything else I may (or may not) be cognizant of that may
> be relevant. For both my enlightenment and that of others.
>
> PPS. For context, this post was also precipitated by my attempt to
> implement some b2 integration for Conan <https://www.conan.io
> <https://www..conan.io>> and CLion integration
> <https://github.com/grafikrobot/clion-boost-build>.

My 2 cents.

Some context: I am a user of cmake, and I use b2 only if required. I 
know VS, Xcode and QtCreator as front-ends, and today I configure 
everything in cmake and use those tools just for ease my development cycle.

I skimmed through this thread, I am in agreement with most of the ideas 
that have been emitted. However, I would like to orient my proposals in 
a different way rather than emitting a set of must have or nice to have 
features: software engineering and development forces, that would be 
beneficial for the b2 community (users and potential developers). I do 
not think those bullets have been addressed, and as most of the people 
know, this infrastructure work is a big amount of work also.

Project maintenance
===================

- it is not clear who is "in charge" of b2. Who are exactly the people 
deciding which actions should be taken? Do those people have the 
bandwidth to cope with a growing community? Who constitutes the core? 
who constitutes the committed developers?
If we want to support a growing community, those information should be 
clear or clarified. See for instance http://scons.org/contact.html . If 
ppl want to use b2, they should feel that there are ppl backing up and 
helping out. On my side, I feel like Steven Watanabe and Vladimir Prus 
are the only core.

- how do we contribute to b2? Is there any good way of writing modules? 
Any coding style? As a user (and hopefully/maybe contributor) I would 
like to see good instructions stated somewhere (and outside of the boost 
umbrella as well). I just saw this page 
https://github.com/boostorg/build/blob/develop/CONTRIBUTING.rst, sorry 
if I missed it .

Installation/deployment
=======================
- If I were to use b2 in another project, I do not want to clone or 
download boost[tarball] for that. I am not proposing having an 
installer, but having a clearly identified set of files that would 
contain what b2 and its modules are. Maybe it would mean at some point 
moving or adapting some files from boost and that are specific to it 
into there. Sorry if I am saying something that is already in place, but 
I have the feeling that the cost of running b2 without boost is not 
negligible (and with most of the bullets here I am certainly wrong :) ).
So, if I just clone boost.build on a almost naked system with a build 
chain, and have project with one Jamfile, would that just work?

Documentation
=============
- there are currently several documentations, and in different places. 
It is good (for referencing) and bad (for confusion). A quick look shows
- http://www.boost.org/build/doc/html/bbv2/builtins/testing.html
- http://www.boost.org/build/tutorial.html
- 
http://www.boost.org/doc/libs/1_62_0/doc/html/bbv2/tasks.html#bbv2.builtins.testing
- https://trac.lvk.cs.msu.su/boost.build/

I would rather merge all of those into a single one. If one of the 
target is to be out of the boost umbrella, then I would also favor a 
dedicated website. Those are for free on GitHub, ReadTheDocs, etc. and 
Jekyll for instance is very easy (and the changes can be tracked within 
the repository as well).

- I would go for a unique language for documentation. Be it QBK (easier 
than boostbook) or md or sphinx or doxygen. Quickbook however would 
mean that it stays tightly coupled with boost (except if quickbook is 
being distributed standalone). I can work on that if you want and/or if 
needed.

- I would think of a way to integrate and extract documentation into the 
modules and the code. CMake has something that is working fairly well 
for the modules documentation (uses Sphinx as backend), but this will 
definitely help to see what module available and how to use them. Maybe 
http://pandoc.org/ can be integrated there to convert from reST to 
docbook (just guessing).

- I think the project should make a good use of the wiki feature of 
GitHub as a starting point with boost.build. I believe there should be a 
single point there as well, since some information are also in 
boost.build bug tracker https://trac.lvk.cs.msu.su/boost.build/. I can 
work on that as well if needed.

- I would really like to see the current design architecture as a drawing :)

Tests
=====
- If I want to use b2, how do I debug what I am writing? In CMake I just 
use the available "printf" (message(FATAL_ERROR blablabla)) and I am 
fine with that. Is there such a thing in b2 and Jam?

- If I want to add a feature to b2, how do I test it? How do I say that 
I am in such environment, so I want a specific set of features on this 
environment and I am running specific tests for it?

- I can see that there are travis tests. What is currently covered? Any 
interests in having more testers with other type of environments?

- In https://github.com/boostorg/build/tree/develop/test I can see only 
python files. Is that enough for the testing purposes? Don't you think 
that having Jamfiles as well here would be testing complementary things 
and being at the same time a source of documentation?

Repository organization
=======================
- This is a bit related to what is above, but how is the repository 
currently organized? I can see for instance a "website" AND "doc" 
folders, a "notes" folder etc. Where are the modules supposed to be?

- Why would contributions go to a "contrib" folder? Aren't contributions 
first class citizens? (and BTW, why would tntnet be integrated into b2 
repository?)

- Ideally, I would like to understand the main components of the project 
just by looking at the top folders in the repository.

I cannot say I can contribute much, but I am willing to do things that 
may be easy for me to handle and that do not require much of my 
neurons+time. As a user, I am really struggling with the Jam language, 
and I really do not understand what features are already in place 
(neither how to do simple things). This makes me feel like the project 
is too much boost centric (although many ppl in there are using it for 
projects outside of boost, but I believe it is a niche and this is what 
this thread is also about).

To that extent, I consider myself as a good example of potential 
contributor, that is having a hard time to dig into the project itself. 
I do not have the 10+years of experience+historical background with b2, 
and for my own ecosystem the project is in competition with what I have 
already (essentially cmake and IDEs) that are doing the job quite ok.

What I can provide is small chunks of work there and there (+ some 
motivation), and this may be a good focus to orient the project such 
that it can also work with this kind of contributions. The bullets 
listed above are to my opinion raising issues in that sense.

Thanks for all the work,
Raffi