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.
Yes.
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.
Yes.
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++ projects
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 Boost.Build.
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. Jeff