John Torjo wrote:

I haven't used eclipse, but I've used bjam. So I'd really expect a LOOOOT of problems.

I second that. And I would advise you to use a real build system instead of bjam to circumvent these problems (no pun intended, guys)... :) Okay, seriously, using external build tools with Eclipse is a pretty straightforward process. As long as the build system is working as intended, there shouldn't be any problems. Just disable Eclipse's "managed building" (enabling user defined makefiles) for your project and tell Eclipse which tool to call to start the building process. I did not tested this for bjam, but for visual studio (devenv.com) and CMake it works really nice. Regards  Hendrik ------------------------------------------------------------------- Brilliance is typically the act of an individual, but incredible stupidity can usually be traced to an organization. - Jon Bentley Hendrik Belitz, Computer Scientist email: hbelitz@computer.org

Hi there, first of all: thanks to all who have responded! I understand that a) using bjam with Eclipse is quite straight forward (I'll let you know about my experiences) b) some people do not quite like Boost.Build As per the second point: What *portable* build systems do critics of Boost.Build recommend and (without wanting to start a flame-war), what problems should I expect if I use Boost.Build anyway ? My purpose here is: I want to release some code to the public under the GPL. The initial user base will likely run Linux systems, but I hope that my code is portable enough so that eventually someone, somewhere compiles it on Windows. I already know that it runs on Macs. So I do not want to introduce additional complications by using a non-portable build system. Boost.Build certainly appears to be portable, and given that my code uses Boost libraries in some places, it is the obvious choice. It certainly is easier to use than the autobuild/libtool/make combo. On a side note I noticed, that bjam is not installed by default (see my corresponding post on the boost.build list) in 1.34.1. Why is this ? Thanks and Best Regards, Ruediger

Note: I'm terribly biased in my opinions, for obvious reasons. But... Mika Fischer wrote:

* Ruediger Berlich [2008-02-15 19:05]:

...

What *portable* build systems do critics of Boost.Build recommend

I'm not a critic of Boost.Build - I actually have never used it.

But I'm quite happy with CMake (http://www.cmake.org/), which seems to gain support in the open-source world and will probably appeal more to Windows developers used to Visual Studio because it has a GUI and can generate VS project files.

Cmake is *technically* not a build system. It is a meta-build system. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

on Mon Feb 18 2008, Hendrik Belitz wrote:

Rene Rivera wrote:

...

Cmake is *technically* not a build system. It is a meta-build system.

Okay, thanks for clarifying that. Although I think that Rüdigers is looking for something you call meta-build system in fact.

Rüdiger,

There is nothing wrong with Boost.Build. It works as it should, and it is a very sophisticated alternative to gmake and nmake, offering a much clearer syntax and platform independence. But it is still a low-level build tool

I'm keenly aware of several Boost.Build shortcomings, but that's just not accurate.

like it's competitors.

Hard to say without knowing what you consider to be its competitors.

Expect to do a lot of of things by hand which can be solved easily in a automated way by using something Rene called a "meta-build" system.

The distinction between "build" and "meta-build" is not low- vs. high- level. The only difference is that a meta-build system uses an intermediate build language and a (non-meta) build system does not. You can create a "non-meta" build system that is arbitrarily high-level, automating as much as you might like. In fact, Boost.Build is a high-level build system built atop a low-level substrate called "bjam."

This is especially an issue for open-source projects which often rely on other toolkits and libraries already installed on the system. There are definitely some pretty neat ways to define automated detection rules for these external dependencies in Boost.Build (in fact, you can do these things which any build system), but this might involve a tedious amount of work; this is something you can just circumvent by using a higher-level tool like automake or (for people who dislike automake's approach) CMake.

It sounds like you're confused. Either the high-level tool does the work for you or it does not. In many cases Boost.Build is able to do this sort of detection, just as CMake or automake would, and I'm willing to be that it has some detection capabilities that neither of the others has. The advantage of a meta-build approach used in CMake and automake is that they can spend arbitrary amounts of time on detection (once) without slowing things down every time through the compile/edit/debug cycle.

Another good point is the generation of platform-dependent makefiles or project files which integrate seamlessly in your current development environment.

Not true for CMake. You can't decouple the generated makefiles from CMake and expect to continue development for very long, because CMake writes *extremely* low-level makefiles that don't even handle such things as header dependency management.

Using Eclipse, who might want to have eclipse project files for you source tree. For Visual Studio or KDevelop, you also want to have building and dependency information.

OK, for IDE project files, that's true... provided that the IDE can represent the same kind of high-level information that is represented in your high-level build system.

Using low-level build tools, you have to generate these things by hand. Using high-level tools, the output will match your desired development environment.

That is not a low-level vs. high-level difference, but simply an important feature difference. Boost.Build doesn't have the ability to generate IDE project files yet, so that is an advantage of CMake (but not of automake).

To summarize this, low-level tools enable you to use a "define once, build everywhere" approach, while high-level tools support the more generalized of approach of "define once, develop everywhere". While this doesn't matter for smaller projects, the latter approach is preferable for all projects involving several developers, maybe even on different developing platforms.

All true, but not a distinction that applies to Boost.Build, which was designed with "define once, develop everywhere" in mind, and achieves that goal admirably. -- Dave Abrahams Boost Consulting http://boost-consulting.com

How about this for a constructive suggestion. Before doing the work of figuring out how to best utilize bjam from withing Eclipse, It would be a good idea to familiarized yourself with bjam/boost.build in the way it is most commonly used. If after this, you are comfortable with how it works and still want to do this, I'm sure it would be easy to find a way to invoke from Eclipse. Robert Ramey Deane Yang wrote:

Hendrik Belitz wrote:

...

John Torjo wrote:

...

I haven't used eclipse, but I've used bjam. So I'd really expect a LOOOOT of problems.

I second that. And I would advise you to use a real build system instead of bjam to circumvent these problems (no pun intended, guys)... :)

I think these comments are uncalled for. You two are expressing your distaste for Boost Build itself and are not commenting on the original question (which is about using bjam as the build tool within Eclipse). So all you are doing is muddling the discussion.

Hi Sebastian (or anyone else), I am trying to integrate bjam with Eclipse and I am able to compile my project. The only thing is that the output of bjam is written to Eclipse's console-window and I am not able to navigate through the errors and warnings. I expected some option to send the output to Eclipe's problems-window enabling me to navigate through warnings and errors. Is this currently by any means possible (I am using Eclipse 3.2.2)? Cheers, Andrej Sebastien Fortier wrote:

We use eclipse (europa) and bjam under Debian Linux "etch" and "sarge" on a daily basis and it works very well, I would be happy to assist you. I would not think of using any other build system!

Ruediger Berlich wrote:

...

Dear all,

I am using Eclipse/CDT under Linux as my standard IDE. So far I'm building my projects using Eclipse's own build mechanisms. Is anybody using bjam as a build mechanism in Eclipse/CDT and should I expect problems when making a switch to bjam ?

Thanks and Best Regards, Ruediger

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

--

Sébastien Fortier

Analyste-Programmeur Scientifique Centre Météorologique Canadien

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- View this message in context: http://www.nabble.com/Eclipse-integration-of-bjam-tp15482773p16413113.html Sent from the Boost - Users mailing list archive at Nabble.com.