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

Subject: Re: [Boost-build] The future of B2?
From: PJB (darthpjb_at_[hidden])
Date: 2016-09-28 09:03:21

​​
On 28 September 2016 at 13:11, Klemens Morgenstern <
klemens.morgenstern_at_[hidden]> wrote:

> I don't think so. From my experience there are a lot of applications that
> are not supported by an IDE, really. That is, if you go into embedded
> development you either have a very narrow project config (e.g. eclipse
> makefiles) or you don't have any whatsoever. I've seen companies writing
> only custom makefiles for their code and I think that is what happens when
> you get to do something (or have a tool) that is not supported by the IDE.

Actually, this is what I was attempting to get at, when developers *have to
do something not supported*. Embedded development is a great example as
traditionally this was done through custom toolsets and makefiles, though
in the last fews years I've seen a few uC companies moving to a Visual
Studio-driven approach (Amtel Studio being a good example). Even in these
environments of non-IDE development, the moment a tool or toolset becomes
available that can support an IDE, it's often not long before the old
approach is abandoned (at least for more agile companies).

​
​
On 28 September 2016 at 13:11, Klemens Morgenstern <
klemens.morgenstern_at_[hidden]> wrote:

> ​
> The problem with boost.build is: it does it's job, but it is hard to use
> outside of boost (especially the setup) and his has basically NO IDE/Editor
> support. But I think, if we had a boost-build3 which would not have those
> limitations but the concepts of bb and would provide a way for an IDE to
> know what the major targets and there properties will be, we might be able
> to make it more widely used and provide IDE (e.g. eclipse) plugins and even
> get one for Visual Studio. But it would be the second step; the first would
> be to get a more solid build system.​

​
I agree mostly, except for the last sentence, ​I believe that the focus
would be better placed on creating a usable build system with a typical
subset of solid support beneath. Creating the perfect build-system will not
happen until every possible usage has been identified - and no single team
will accomplish this.
Meanwhile, having a solid build system for the majority of typical
platforms (MSVC, Mac, standard Linux distros, etc), will lead to wider
usage and in turn more requests, fixes, and community contribution.

If boost-build was even remotely usable at the company I work for, I would
gladly put in the hours needed to make working OSX 10.6 builds using it
(which is a nightmare, even in the Xcode IDE apple provides). However as
build is not easily integrated into my companies workflow, that cannot
happen.