What is Boost Jam and is Jam worth migrating to?

Question

What is Boost Jam and is Jam worth migrating to?

I understand that jam is build system built by perforce however I am not sure how the boost jam & regular jam is different.

I'm also hoping there could be someone in the SO community who has worked with it and maybe can highlight some differences and/or benefits.

Abbasid

Answer 1

For my purposes, it's just the thing that builds the boost library for you, I wasn't aware you could do anything else with it so I don't understand what you could mean by migrating to it. And I'm sorry but I'm unaware what regular jam is. Since no one else has provided an answer I'll just provide my understanding of it.

Boost is a collection of classes and functions for C++ are useful for various tasks. The classes and functions of boost are grouped into libraries. Some of the libraries have all their code in header files which you can use simply by using an #include preprocessor statement, while others (such as the filesystem or regular expressions library) have part of their implementation in .cpp files.

Compiling these .cpp files can take ages (it's like 30 minutes depending on what you're compiling) and it would be a real pain if it took half an hour every time you wanted to recompile your program. So what they have done is only for those libraries that are partly stored in .cpp files, you can precompile them into a .lib file, and that's the purpose of boost jam. That means you only have to spend half an hour compiling them once, and from then on you never have to wait half an hour again.

However, as you can imagine, each boost library consists of many cpp files and many header files, and there are many different flavours of each (debug versions, release versions, multi-threaded, etc) and so it is not a simple process to just compile the boost library yourself. That's where boost jam comes in. You give it the command to compile the libraries and then it issues all the commands for you to the compiler, and by the end of it, you'll have a collection of precompiled .lib files, one for each different flavour of each library. The header files somehow tell the linker which lib files to include, so if you have the correct paths setup, the correct flavour of precompiled .lib file will automatically be linked to your program, thus saving you a 30 minute compilation.

You can see what libraries need to be compiled by boost jam and what libraries don't by looking at this page: http://www.boost.org/doc/libs/1_37_0 - if a library does not need a lib file (and therefore does not require you to mess with boost jam first), it will say "Build & Link: Header only" whereas if a library does require you to precompile a lib file, it will say "Build & Link: Automatic linking".

Also, if you are on Windows, you can download the precompiled .lib files so you never have to use boost jam. To get that, what you should do is go to the www.boost.org page, go to the Getting Started section and follow it all the way through just to make sure you have everything setup correctly. One of the links on the windows version of that page tells you where to find the precompiled .lib files.

Wilder

Just want to be clear that I'm only posting this because I thought it might be useful. I've never used jam but it's been days and no one answered this guy, so I decided to answer out of the little knowledge I have. – Wilder

Other comments (possibly added later) tell that Boost Jam is a build system; so it goes beyond compilation of boost libraries themselves. – Stillwell

This answer is just awefully wrong and misinformed. – Inimical

Answer 2

I use Boost Jam for my cross-platform C++ development. I chose it because

• I want my code to build everywhere Boost builds,
• it uses a relatively simple declarative language to specify how to build targets, and
• it can build all the different flavors of your binaries (e.g. debug vs. release, 32-bit vs. 64-bit, msvc vs. gcc) in a single invocation with an absolute minimum of flavor-related exceptions in the build declarations.

You can refine generic rules with flavor-specific settings, rather than writing separate rules for each flavor permutation. The syntax isn't exactly what I would have chosen, but it's not too hard to get used to.

This paper compares Boost Jam to CMake, SCons, and Eclipse CDT: http://syrcose.ispras.ru/2009/files/04_paper.pdf

My understanding is that Boost Jam is an offshoot of Perforce Jam maintained by the Boost community, and that Perforce Jam isn't actively maintained anymore (the release notes have the last update in April 2003).

Of course, if you don't care about cross-platform development, there are easier ways to go, as others have mentioned here. Personally, I keep meaning to revisit Eclipse CDT; it didn't seem usable 5 years ago, but I hear it has come a long way.

Misread

Since this answer still occasionally gets up-votes, I want to note that my subsequent work switched to CMake. While it's not perfect, I'd recommend CMake today over Boost Jam, due to its IDE support and popularity/"well-knownness". Eclipse CDT is very useful as an IDE, but doesn't provide a build system. – Misread

Answer 3

As you state, Boost Jam is a build system, and can be used independently of any other boost libraries. I don't know anything about Perforce Jam, but to my understanding, Boost jam is very similar, and mostly compatible.

The main difference is that Boost Jam often comes with Boost Build, a collection of jam rules designed for common tasks, e.g. compiling libraries, running unit tests, creating doxygen documentation, etc.

Compared to other build systems, Boost Jam/Boost Build is designed for easily compilation of different variants. So if you want to change compilation settings from debug to release, or single- to multi-threaded, it determines a lot of the changes automatically.

The drawback is that the syntax is very finicky, and outside the boost website, there's no good documentation. But I imagine Perforce Jam is just as bad in that regard.

Thackeray

Agree, the syntax and the whole process is not that intuitive – Hypoglycemia

Answer 4

Given the choice of build tools I would not migrate to jam. There are better build systems out there - CMake / SCons for C/C++, qmake for Qt, Ant for Java, NAnt and MSBuild for .NET, and so on. They might not be technically superior but they will be less painful to use simply because far more people are familiar with them (on the other hand, they might be technically superior, of course :D).

W

-3 for SCons. See this 3-part blog series: electric-cloud.com/blog/2010/03/08/how-scalable-is-scons electric-cloud.com/blog/2010/07/21/… electric-cloud.com/blog/2010/08/11/… – Misread

I'm sorry, in March 2009 my time machine was malfunctioning, otherwise I'd have traveled to August 2010, found out about any scalability issues, then returned to 2009 to not include that :) Jest aside, SCons might become problematic if your project grows very large, but for most small to medium size projects it's perfectly fine. Edit: Full disclosure - I use CMake :) – Heartthrob

:-p The scalability problems were there in March 2009, just not the blog post. The impetus for the comment wasn't the blog post anyway -- I only included it as evidence; it was rants from former coworkers about their experiences with SCons build times. – Misread

Heh :) By now it's quite moot anyway - for example, I use premake now (see industriousone.com/premake ). – Heartthrob

At a previous company (circa 2005) I rewrote a build system that used make (builds would take 14 hours) to jam (builds took 15 mins). Management was impressed, but it was very difficult for individual engineers to learn a new build system and I ended up being the build engineer. It is now 2016 and there are major new build systems such as Bazel (bazel.io). It is interesting how much software engineering has changed in the past 10 years. In 2005, most people would not do full builds of 1M SLOC on their personal workstations as they weren't powerful enough. – Grigri