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

Subject: Re: [Boost-build] The future of B2?
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-09-28 09:17:29

Am 28.09.2016 um 15:03 schrieb PJB:
>
> ​​
> On 28 September 2016 at 13:11, Klemens Morgenstern 
> <klemens.morgenstern_at_[hidden] <mailto: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).
>
So what's the problem? You need an IDE Integration?
>
>     ​
>     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.
That's why I hope for an extensible system, so you can write a plugin. 
I.e. if you were able to write a plugin for VHDL development, you'd have 
a powerful beast. But you're right, it's quite hard, though I believe 
one could cover the majority of problems.
> 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.
>
I actually use boost.build with eclipse (on windows) and there I just 
integrated it as a custom build command. I do have to write jam-files by 
hand, but I literally click on build and it starts. And then I have 
different settings to build tests etc. - I really don't think it would 
be that big a deal to integrate it into the IDE; it just doesn't make 
sense, since there are very few people using boost.build this way.
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build