Future of Boost.Build

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Future of Boost.Build

Boost - Build mailing list
Now that the shit has hit the fan, what will become of Boost.Build? I still prefer it to CMake even if Boost won't use it (whether I can convince my project to keep using it may be another matter). I have greatly appreciated Steven's, Vladimir's, and Rene's improvements over the years.

Rene, can you expound on what you mention here?
* I will continue to maintain Predef. But will be forking it into a
non-Boost form moving forward (in similar vein to ASIO).

* I will *not* continue to maintain B2 in the Boost form. I will be
rewriting b2 into a new form to address the needs of building software that
matches the industry I work in. I will be doing this immediately.

What does it mean to rewrite b2 in "a new form" that "that matches the industry I work in"?

I will be particularly irked if the Boost SC ends up hiring contractors to speed the conversion to CMake, when the issues in Boost.Build (documentation and it being quite hard to learn how to do advanced things with it) could be solved by far less contracted effort.

-Matt

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Future of Boost.Build

Boost - Build mailing list
On 7/26/2017 2:18 PM, Chambers, Matthew via Boost-build wrote:

> Now that the shit has hit the fan, what will become of Boost.Build? I
> still prefer it to CMake even if Boost won't use it (whether I can
> convince my project to keep using it may be another matter). I have
> greatly appreciated Steven's, Vladimir's, and Rene's improvements over
> the years.
>
> Rene, can you expound on what you mention here?
>> * I will continue to maintain Predef. But will be forking it into a
>> non-Boost form moving forward (in similar vein to ASIO).
>>
>> * I will*not*  continue to maintain B2 in the Boost form. I will be
>> rewriting b2 into a new form to address the needs of building software that
>> matches the industry I work in. I will be doing this immediately.
>
> What does it mean to rewrite b2 in "a new form" that "that matches the
> industry I work in"?
>
> I will be particularly irked if the Boost SC ends up hiring contractors
> to speed the conversion to CMake, when the issues in Boost.Build
> (documentation and it being quite hard to learn how to do advanced
> things with it) could be solved by far less contracted effort.
>
> -Matt
>
>
I agree with you that improving Boost.Build documentation is a better
solution.  I for one dislike and barely tolerate the cumbersome and
error prone method getting CMake to create the correct output for even a
single architecture and tool like Visual Studio.  Once CMake finally
succeeds with something like 64-Bit, Visual Studio, then the individual
Visual Studio solution and sub-projects are manually edited, adding
support for selecting 32-Bit, Debug/Release and the Intel compiler on
Windows.  Once I find where the CMake command invocation scripting is
hiding in a project file, it gets deleted to prevent CMake overriding
the now correctly building solution for compiler, architecture and bit
setting combinations.  Note how the SC has been rather quiet on the
developer list since the "... intent ..." announcement.  In comparison,
the crickets near the rental home are much more vocal every night.

--Robert


> _______________________________________________
> Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
>

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Future of Boost.Build

Boost - Build mailing list
In reply to this post by Boost - Build mailing list
Now that I'm back from my travels have some time to actually compose something reasonable for this.. Which I was going to do tonight anyway :-)

On Wed, Jul 26, 2017 at 2:18 PM, Chambers, Matthew via Boost-build <[hidden email]> wrote:
Now that the shit has hit the fan, what will become of Boost.Build? I still prefer it to CMake even if Boost won't use it (whether I can convince my project to keep using it may be another matter). I have greatly appreciated Steven's, Vladimir's, and Rene's improvements over the years.

Rene, can you expound on what you mention here?
* I will continue to maintain Predef. But will be forking it into a
non-Boost form moving forward (in similar vein to ASIO).
That plan is.. I'm going to write a version of Predef that doesn't have the "BOOST_" prefix on it. And generate the Boost version from it. That way I can advertise Predef outside of Boost. As my industry, game development, is still reticent to deal with anything Boost (and some in some notable instances not even STL). And I'm seen the equivalent of Predef reimplemented in every C++ project I've seen. So I'd like to see wider usage of Predef. Hence I'm hoping this is the way to do it.
* I will *not* continue to maintain B2 in the Boost form. I will be
rewriting b2 into a new form to address the needs of building software that
matches the industry I work in. I will be doing this immediately.

What does it mean to rewrite b2 in "a new form" that "that matches the industry I work in"?

 Right.. Note, the following is what I want to happen not necessarily what will happen. As this is also the first time the rest of the b2 devs see this. So here goes..

First:

* The current b2 will get a cleanup and re-documentation pass.
* It will still operate the same way it does now.
* It will get improvements and adjustments.
* It will be easier to obtain (i.e. installers, website outside of Boost, etc).

Second (although not necessarily sequentially):

* Rewrite b2 in a modular way to support uses other than the current b2 incarnation.

Ok, that was short and I should explain more. Over the years in my industry, i.e. game development, I've worked on various systems. I've spent much of that time writing and enhancing tools of all kinds. But almost for most projects I've had to deal with either tweaking or writing new build systems. The most recent of which was writing an entirely new build system a couple months ago. One aspect that doing that is the realization that everyone wants to make some custom build system and they are faced with re-inventing all of it each time. I personally feel that this is one of the largest drags on the quality of build system at the moment. What I want to do is rewrite b2 such that it's based on parts that others can use to create other tools for building. One of those tools would obviously be the current b2 frontend itself. But there's also the current b2 Python port, the faber tool from Stefan, b2 server/service helper, and tight IDE integration modules to name a few. For this the general approach would be to incrementally tear chunks out of the b2 engine (the C part) and replace them with well thought out and documented equivalent library. There's obviously way more detail to hammer out on this. But that'll be in other discussions.

The big question from me in the above is.. What do you (that's a royal you for anyone on this list) think of the approach?
 
I will be particularly irked if the Boost SC ends up hiring contractors to speed the conversion to CMake, when the issues in Boost.Build (documentation and it being quite hard to learn how to do advanced things with it) could be solved by far less contracted effort.

Indeed.

And thanks for asking.


--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/skype,efnet,gmail

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Future of Boost.Build

Boost - Build mailing list
In reply to this post by Boost - Build mailing list
On 26/07/2017 22:18, Chambers, Matthew via Boost-build wrote:

> Now that the shit has hit the fan, what will become of Boost.Build? I still prefer it to CMake even if Boost won't use it (whether I can convince my project to keep using it may be another matter). I have greatly appreciated Steven's, Vladimir's, and Rene's improvements over the years.
>
> Rene, can you expound on what you mention here?
>> * I will continue to maintain Predef. But will be forking it into a
>> non-Boost form moving forward (in similar vein to ASIO).
>>
>> * I will *not* continue to maintain B2 in the Boost form. I will be
>> rewriting b2 into a new form to address the needs of building software that
>> matches the industry I work in. I will be doing this immediately.
>
> What does it mean to rewrite b2 in "a new form" that "that matches the industry I work in"?

Matt,

it's probably to early to make any definite plans. However, if we decide that Boost.Build project
no longer cares about requirements of Boost C++ Libraries project, then it would be reasonable to
adjust priorities as follows:

- as opposed to having bootstrap.bat/bootstrap.sh process that tries to support zillion host compilers,
   focus more on installers. Maybe only support bootstrapping with gcc and msvc.
- declare that we only care about Python version. It was original requirement of Boost C++ to not depend
   on large external packages, but in 2017, an installer with Python in it can be downloaded and installed
   in a minute.
- focus on designing a Python interface for defining build targets.
- drop BoostBuild documentation, rewrite docs using Markdown/GitBook or maybe even using GitHub wiki.

That's just my personal list.

Thanks,
Volodya


_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Future of Boost.Build

Boost - Build mailing list
In reply to this post by Boost - Build mailing list
On 26.07.2017 23:12, Rene Rivera via Boost-build wrote:

[...]

> Ok, that was short and I should explain more. Over the years in my
> industry, i.e. game development, I've worked on various systems. I've
> spent much of that time writing and enhancing tools of all kinds. But
> almost for most projects I've had to deal with either tweaking or
> writing new build systems. The most recent of which was writing an
> entirely new build system a couple months ago. One aspect that doing
> that is the realization that everyone wants to make some custom build
> system and they are faced with re-inventing all of it each time. I
> personally feel that this is one of the largest drags on the quality
> of build system at the moment. What I want to do is rewrite b2 such
> that it's based on parts that others can use to create other tools for
> building. One of those tools would obviously be the current b2
> frontend itself. But there's also the current b2 Python port, the
> faber tool from Stefan, b2 server/service helper, and tight IDE
> integration modules to name a few. For this the general approach would
> be to incrementally tear chunks out of the b2 engine (the C part) and
> replace them with well thought out and documented equivalent library.
> There's obviously way more detail to hammer out on this. But that'll
> be in other discussions.
>
> The big question from me in the above is.. What do you (that's a royal
> you for anyone on this list) think of the approach?

I agree. There are quite a few idiosyncrasies that have crept into b2 to
support Boost-specific policies that I think a general-purpose build
tool shouldn't have (or that should be captured in a higher layer to
adapt the tool to a specific work-flow), but there is a substantial set
of generic features that each and every build system needs. Agreeing on
that core set of features and putting that into a form that's reusable
by others to define their own workflows would be very valuable.

I have tried to do that in Faber (where bjam survived as the scheduler,
but everything on top of it is rewritten in Python from scratch), and I
would definitely like to compare and share with others.

        Stefan
 

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Loading...