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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk