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

Subject: Re: [Boost-build] The future of B2?
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2016-10-01 00:14:09

On Tue, Sep 27, 2016 at 3:19 PM, <aaron_at_[hidden]> wrote:

> > 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.
>
> This is probably the biggest feature request from all of our
> 400+ developers.
>
Check.. And wow, 400+!

> > 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 have toyed with this idea and I like the idea of plugins. A plugin
> extends the build system by allowing to register a new tool/toolset or
> by registering types, features, generators, etc. What I have planned out
> is to use Python and it's package management in order to set up these
> plugins. Each plugin would be a Python package (a directory with
> an __init__.py) and would contain other modules e.g. types.py, features.py,
> generators.py, etc. The plugins would be laid out in a logical manner like
> this so that all features, types, etc. were guaranteed to exist during all
> parts of target declaration. Additionally, this makes it easy to
> document each thing. types.py will only contain type registrations so
> we can easily document those types. Another potential module within a
> plugin could be args.py. This is where all command-line flags could
> be registered with the build system so that running --help on the
> command line would show each plugin's help message. I would imagine
> argparse's ArgumentParser could be used for this. A plugin can be
> "installed" in two ways: either by placing the Python package in
> the project's directory or by using Python's package manager, pip,
> to install the extension. In order to register the plugin with the
> build system, a Jamroot/build.jam will need to call plugins.register()
> with the path/to/package or the qualified.python.package.name depending
> on how the plugin was installed.
>
Interesting.. However we decide to approach this particular problem I would
strive for making it easy to for both producers and consumers of
plugins/extensions. Which as you've probably noticed is rather hard when we
deal with something as loosely modular as b2 is at the moment.

> > 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.
>
> As said in a separate thread, my company has been using the Boost.Build
> Python port to build all of our embedded software written in C. We've
> written our own library/extensions that allows us to work with the ARM
> and ADI Blackfin toolsets and we have several tools that help us to
> peform some sort of generation of code. We've been able to build with
> the Python port for about a year now (there are a few changes I've had
> to make to the core in order to get this to work that I haven't created
> a Pull Request for yet as I wasn't sure if it would break anything).
>
Awesome :-)

> The Python port is not a fixall, for sure, but it seems to be easier
> for most developers to grasp (vs. Jam). This does not solve the problem
> of them having to understand how the build system works, however.
>
Not sure what to do about that. At some level there has to be some
understanding. But perhaps this is what Edward is referring to. IF we make
it clearer where commands come from it will be easier to understand.

> The daemon branch was written with only Linux support, so it still needs
> to be updated to be cross-platform. I think I can do this with the help
> of a Python package named Watchdog for file system notifications and
> can just rely on Python itself for creating the daemon process. I think
> this branch along with the work that Volodya has already done on the
> the server branch are absolutely necessary in order to get
> "I want all that to perform as expediently as possible when I hit the build
> (or whatever button) in my IDE".
>
Perhaps.. Although I have some ideas that don't rely on that kind of
overwatch design. But I also suspect that having an overwatch server of
some sort will likely be needed in the end for some things. We'll see :-)

> The only downside to the Python port, that I can see, is its speed. I
> believe
> I can correct some of this and will attempt on making it at least as fast
> as Jam currently is.
>
I think that in the end we'll end up with the same kind of arrangement as
we have now. Of having multiple languages to deal with the different
domains involved. So things like that being slow don't bother me as much at
this point.

> Lastly, an additional feature that I would like to see is the ability
> to provide custom project loaders. For some of our developers here, the
> Jam langauge has given them such heartburn that they have refused to use
> the build system altogether. A custom project loader would allow for
> declaring
> targets in different declarative formats like XML, JSON, YAML, etc. I
> realize
> that targets can be declared solely in Python, but I have seen some
> developers
> shoot themselves in the foot when given a full programming language, stuff
> like
> touching files during the metatarget phase to force builds, etc :(
> This group/kind of developers do not want to learn how to use tools and
> they just want to have a play button that does everything for them.
>
This is certainly a good idea. In particular when it comes to IDE
integrations. As it's much easier to sell a build solution that reads the
project description that most IDEs already keep around.

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