On 28 September 2016 at 13:11, Klemens Morgenstern <klemens.morgenstern@gmx.net> 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@gmx.net> 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.