How can I build different versions of a project using the Jam make tool?

Question

I have a C++ project that compiles to different versions, including release, debug, shared library, and executable, with different compiler flags for each. I am trying out Jam as an alternative to Make, because it looks like a simpler system.

Is Jam capable of this? The main problem is that it always places the .o files into the same folder as the source file, so it overwrites them when building multiple versions.

Update

I found a solution that seems to work. Using this file, I can build debug and release configurations of a library or executable.

Command to build release library:

jam -s config=lib -s release=1

If you only type jam, it builds the debug executable. Here is the Jamfile:

FILES = 
    main.cpp 
    ;

BASENAME = steve ;
OBJ = obj ;

if $(release) 
{
    OBJ = $(OBJ)r ;
} 
else 
{
    DEFINES += DEBUG ;
    OBJ = $(OBJ)d ;
}

if $(config) = lib 
{
    OBJ = $(OBJ)_lib ;
    OUTFILE = lib$(BASENAME).so ;
    DEFINES += SHARED_LIBRARY ;
    LINKFLAGS += 
        -shared -Wl,-soname,$(OUTFILE) -fvisibility=hidden -fPICS 
    ;
} 
else 
{
    OUTFILE = $(BASENAME) ;
}

LOCATE_TARGET = $(OBJ) ;
MkDir $(LOCATE_TARGET) ;
Main $(OUTFILE) : $(FILES) ;

Answer 1

The popularity of the build system is important, because it means more people in your organization (and future employees) are likely to know it and be able to support it.

I would say don't do it. Don't use Jam. Does anyone but boost use it, anyway? I think Ant, for example, is a much more popular system and I find it easier to learn. Do your organization a favor and don't touch jam.

Answer 2

CMake has facilities to do this.

But if you already have a build tool in use, it's better to continue using it than to start using another one - especially if there are other members of your team that are accustomed to it.

Answer 3

I'm not familiar with Perforce's Jam however bjam allows this - and it's trivially easy. bjam does not place the intermediate files in the same directory as the source; it creates debug/release/static/shared directories depending on the type of project you're building.

For example if you wanted to build release and debug version of a library and you wanted to build it statically:

bjam debug release link=static

bjam does have some quirks but we've found it very effective. Currently we're using (almost) identical build scripts to build our system using msvc (8.0 and 9.0), gcc 4.3 on x86, gcc 3.4 on ARM and gcc 4.3 for the PowerPC. Very nice.

Answer 4

Yes, it's capable of this. It's called 'variants', boost.build comes with 'debug' and 'release' predefined. It's also possible to add 'features' of your own, defining them as link-incompatible will put generated object files into different subdirectories:

feature magic : off on : propagated composite ;

feature.compose on : USE_MAGIC ;

I find the ease of maintaining co-existing variants is one of the strongest features of boost.build. Also, it's very easy to maintain project hierarchies (e.g., application requiring libraries); this is done on the file level, not by recursing into directories, making parallel builds very efficient.