From: Jeff Garland (jeff_at_[hidden])
Date: 2007-03-03 10:50:45
Bjørn Roald wrote:
> Jeff Garland wrote:
> By the way, http://www.trolltech.com has a similar solution called qmake
> which is used in Qt. This may or may not be more appropriate in an
> optional add-on to Boost.Build.
Non-technical issue: MPC has a boost compatible license -- I doubt QT does.
>> Someone of the folks at OCI previously put together a set of boost project
>> files. Those are in the vault at:
> These seems to be hand crafted. Is that correct? In that case I do not
> think this is the way to go.
>> Note, I haven't tried the Boost files, but I've used MPC on cross-platform
>> projects -- it's a nifty solution.
> Agree, Many developers prefer their native IDE project- , build-, and
> debug-management . The challenges do however soon become clear. Sooner
> or later changes to the native build files must go back to the .mpc or
> jam files. That becomes annoying, error prone, or outright neglected.
> Even if the mpc and qmake have their shiny aspects, I would be much more
> interested in good plug-in support for bbv2/bjam in IDEs such as
> Eclipse/CDE, VisualStudio, etc. In the IDE this should have the look
> and feel of the native build system if possible. This involves:
> - adding and removing source files from projects in the IDE
> - creating new projects
> - starting bbv2 builds which reports errors into the IDE interface
> - execute or debug sessions should invoke build with bbv2 and offer to
> rebuild first if required
> - saving files could start background builds like in Eclipse managed C++
Yeah, that's a different way, but doesn't this mean that people would have to
use bbv2 for their whole project?
> The funny thing is that I don't care that much myself for these
> features, I am more than happy with emacs + Boost.Build or whatever
> other _real_ build system is I use.
Funny, me too :-)
> What frustrates me is that so many
> developers use build systems that come with their IDE without any regard
> to the possible downsides they bring with them.
Hmm, no kidding -- like the scenario where 20 developers trying to collaborate
and needing to have consistent settings in the project files? So you wind up
with 200 project files with different settings and then you burn a couple
weeks of someones time to get things consistent and setup new common build
targets (yes, it's happened to me). Of course this can trivially be done with
#include and a common makefile with common setting -- something that often
hasn't been available in ide setups (may be now, but I haven't seen it done).
And then there's the 'daily build/regression test' stuff -- still haven't
seen anyone serious about doing this job do it thru and ide.
> Also, I believe real
> IDE plug-in support could be a boost in the popularity of bjam and
Possibly. My sense is that this is a quasi religious issue. There's lots of
projects that will never switch to bjam even if you could prove it's the best
build system ever. So I think producing native ide files instead of trying to
sell bjam gets more boost users in the end.
Boost 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