If there is something better, then I'm totally open to it. SCONs is the only alternative which I consider to be as powerful... I am still in the boat that there is simply not enough *good* documentation to illuminate ideas for a tool which is very powerful. If this means contribute, then I will contribute. Cheers, Tim On Mon, May 12, 2008 at 10:04 AM, Jeff Garland wrote:

On Mon, May 12, 2008 at 6:56 AM, Tim St. Clair wrote:

...

Folks -

I've heard various mumblings from sources regarding the future of BJAM, and I would honestly like to know what the verdict is.

Dave Abrahams suggested in the Future of Boost session that it seems likely Boost will move away from bjam at some future point. When that will be isn't clear.

...

I've also heard a lot of smack about it, which I consider to be more dogma then anything. Also, I must say, as a cross platform developer I have yet to find it's equal, and would perfer to illuminate

It may be, but for every person that thinks like you there's some or more that have issues with bjam.

...

dogma where it may exist, vs. throwing up our arms hold heartedly. If that means developing a users guide to help "boost" them into bjam, then I would be happy to contribute.

I think the predominate issue is the maintenance of the build system itself -- there are very few people that can maintain boost build and we'd rather not be in the tools business where other options exist.

HTH,

Jeff

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

-- Regards, Timothy St. Clair [timothysc@gmail.com]

On Mon, May 12, 2008 at 11:50:08AM -0500, Tim St. Clair wrote:

If there is something better, then I'm totally open to it. SCONs is the only alternative which I consider to be as powerful...

Did you take a look at cmake (www.cmake.org)? The KDE project has recently switched to cmake. Cmake's documentation isn't the greatest either, but: - it has a configuration TUI/GUI (no more questions like "which switch enables 64-bit compilation?) - the reference docs are good - there is a plenty of examples and tutorials floating around - a book is sold on amazon I've recently started to use cmake and, while not quite "comfortable" with it, at least i'm getting stuff done, something I couldn't say for bjam when I tried to use it.

Tim St. Clair wrote:

If there is something better, then I'm totally open to it. SCONs is the only alternative which I consider to be as powerful...

I am still in the boat that there is simply not enough *good* documentation to illuminate ideas for a tool which is very powerful.

If this means contribute, then I will contribute.

All contributions, and documentation contributions especially, are welcome. And please rest assured that Boost.Build will continue to move on. - Volodya

Vladimir Prus wrote:

Jeff Garland wrote:

...

On Mon, May 12, 2008 at 6:56 AM, Tim St. Clair wrote:

...

Folks -

I've heard various mumblings from sources regarding the future of BJAM, and I would honestly like to know what the verdict is.

Dave Abrahams suggested in the Future of Boost session that it seems likely Boost will move away from bjam at some future point.

May I ask if this year, the presentation slides will be available to general public, or will remain available to only select few? If no, then I think any further discussion either on this list, or on boost-build mailing list, makes no sense.

I don't think this session had any slides besides there was no discussion as to making slides public which I would consider necessary before making them public! -- Sohail Somani http://uint32t.blogspot.com

Doug Gregor wrote:

Several of us are working on a CMake-based build system that will use Bitten for its regression-test reporting. For the curious, there's information on the Boost Trac (and a link to the newly-created mailing list) on this project here:

http://svn.boost.org/trac/boost/wiki/CMake

We don't know what Boost will do with the result of this work, and we're not going to guess. What we do know is that we plan to use CMake's ability to build binary installers to try to simplify the distribution of Boost for the major platforms (Windows, Mac). For most end users, the best build system is no build system :)

I'm very excited about Boost's CMake based build system. So thanks very much! At my work (www.lkeb.nl) we already use several third party libraries that are built by CMake, including Kitware's ITK and VTK, and DCMTK by Offis. We're now planning to start using CMake for our own in-house developed libraries as well. Would the current Boost CMake branch (svn/boost/branches/CMake/release) build exactly the same binaries as when running bjam.exe on boost_1_35_0.zip (as downloaded from www.boost.org)? Or could there possibly be some version differences between the two? Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

Doug Gregor wrote:

The Boost CMake branch is tracking the Boost release branch (/svn/ boost/branches/release), so it will have different contents than Boost 1.35.0. It's actually labeled as Boost 1.35.1, on the assumption that 1.35.1 was going to be the next release

Thank you, Doug. BTW, what do you mean by /labeled/? Because the CMakeList.txt file still says that it's version 1.35.0: set(BOOST_VERSION_MAJOR 1) set(BOOST_VERSION_MINOR 35) set(BOOST_VERSION_SUBMINOR 0) http://svn.boost.org/trac/boost/browser/branches/CMake/release/CMakeLists.tx... Anyway, do you have a suggestion for me how to build the official 1.35.0 release by using CMake? Is there a specific SVN revision number I should stick to, when retrieving an update from http://svn.boost.org/trac/boost/browser/branches/CMake/release ? FWIW, I would like to build Boost binaries for both MSVC 2003 and 2008. Kind regards, Niels

Douglas Gregor wrote:

...

Anyway, do you have a suggestion for me how to build the official 1.35.0 release by using CMake? Is there a specific SVN revision number I should stick to, when retrieving an update from http://svn.boost.org/trac/boost/browser/branches/CMake/release ?

We do not have an easy way to do this at the moment. One could perhaps just take all of the CMakeLists.txt files, tools/build/CMake, and the various .cmake files and put them into a Boost 1.35.0 distribution to build it with CMake. I haven't tried this, though.

Let the interested parties repeat this request for a cmakeable v1.35.0 on the boost-cmake mailing list: http://lists.boost.org/mailman/listinfo.cgi/boost-cmake and we'll get it done. This has been on my todo list for a while. -t

Jeff Garland wrote:

On Mon, May 12, 2008 at 6:56 AM, Tim St. Clair mailto:timothysc@gmail.com> wrote:

...

Folks -

I've heard various mumblings from sources regarding the future of BJAM, and I would honestly like to know what the verdict is.

Dave Abrahams suggested in the Future of Boost session that it seems likely Boost will move away from bjam at some future point. When that will be isn't clear.

That wasn't my understanding. I gathered that there would eventually be CMake support for Boost, and that the test infrastructure would be integrated with it via Bitten or something like it. CMake would also be used to build the binary installers that BoostPro offers. But I didn't hear anybody say that BJam support would be dropped, or that BJam development would cease.

...

I've also heard a lot of smack about it, which I consider to be more dogma then anything. Also, I must say, as a cross platform developer I have yet to find it's equal, and would perfer to illuminate

It may be, but for every person that thinks like you there's some or more that have issues with bjam.

"Smack" and "dogma" are your characterizations of a reasoned discussion.

...

dogma where it may exist, vs. throwing up our arms hold heartedly. If that means developing a users guide to help "boost" them into bjam, then I would be happy to contribute.

Thank you for offering to help. Since nobody (AFAIK) is suggesting we drop BJam, your help documenting it would be greatly appreciated.

I think the predominate issue is the maintenance of the build system itself -- there are very few people that can maintain boost build and we'd rather not be in the tools business where other options exist.

True, and a users' guide won't help with that. We need a maintainers guide, too. -- Eric Niebler Boost Consulting www.boost-consulting.com

I am with Tim on the documentation. I too feel that bjam needs better documentation and also more examples of simple, medium, and complex projects. There are some issues with bjam in my opinion having used it for about a year now (longer when I consider we were integrating it with our existing build system) on what I would consider a large scale project. These issues are as follows: 1) Lack documentation concerning the pitfalls of using bjam. Basically common issues people can run into. There are lessons learned from my use I think people may be interested in. 2) Documentation needs to be modified to show use and examples in small (hello world), medium (my wonder wigit), and large (compiling chrooted images on multiple different embedded target computers, and multiple vendors of Linux while supporting Windows builds for shared code). I think this would expose what the current documentation is good at and where it is lacking. 3) Generators seem too complex to construct from scratch 4) Generators need to be compiled/interpreted each build, seemingly, slowing down the build process. I am willing to help in these areas. Like I said at boostcon "Lets fix the problem" if we can. If it is felt that bjam must be scraped in favor of a simpler build system, one that may be maintained by others then I would like to see a build system that is as elegant and syntactically powerful as bjam. Brian On Mon, May 12, 2008 at 10:04 AM, Jeff Garland wrote:

On Mon, May 12, 2008 at 6:56 AM, Tim St. Clair wrote:

...

Folks -

I've heard various mumblings from sources regarding the future of BJAM, and I would honestly like to know what the verdict is.

Dave Abrahams suggested in the Future of Boost session that it seems likely Boost will move away from bjam at some future point. When that will be isn't clear.

...

I've also heard a lot of smack about it, which I consider to be more dogma then anything. Also, I must say, as a cross platform developer I have yet to find it's equal, and would perfer to illuminate

It may be, but for every person that thinks like you there's some or more that have issues with bjam.

...

dogma where it may exist, vs. throwing up our arms hold heartedly. If that means developing a users guide to help "boost" them into bjam, then I would be happy to contribute.

I think the predominate issue is the maintenance of the build system itself -- there are very few people that can maintain boost build and we'd rather not be in the tools business where other options exist.

HTH,

Jeff

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