Boost logo

Boost :

From: Michael Caisse (boost_at_[hidden])
Date: 2007-05-25 12:48:31

Stefan Seefeld wrote:
> Jeff Garland wrote:
>> This is a huge problem with the current sandbox organization. After spending
>> a couple hours the other day trying to get to work in the sandbox
>> tree I gave up in frustration and had to copy sandbox directories into my
>> boost tree to use bjam. This is very annoying to say the least.
> Is this a limitation ? What's the proper way to fix that ?
> Regards,
> Stefan
Unless I mis-understand the problem... this is not a issue at all. In
fact, this is one of the things I love about bjam and the system. For
example, this is a snipping from one of my Jamroot files:


    use-project /omd/common : library/common/trunk/build ;
    use-project /omd/xml : library/xml/trunk/build ;
    use-project /omd/room : library/room/trunk/build ;
    use-project /omd/factory : library/factory/trunk/build ;
    use-project /omd/daemon : library/daemon/trunk/build ;
    use-project /vendor/xerces-c : library/vendor/xerces-c/build ;


As you can see, I use the "recommended" best practice for subversion filesystem
layout (trunk/branch/tag). Personally, this was a total pain; however, I couldn't
think of anything better to do for layout given the size and reuse of many of my
projects. Then I discovered bjam/ and I became a very happy person.
Between the concepts of project id's and usage requirements my build tasks have
become trivial compared to what they were.

In other projects I have a single library sitting parallel to the rest of the
release tree that I'm specializing for a client. Again, the process has been
trivial by simply modifying the Jamroot project id to point elsewhere.

This may be an issue with the Jamroot project definitions, but it is not a
limitation of bjam/

Now you can tell me I didn't understand the problem (o;


Michael Caisse
Object Modeling Designs

Boost list run by bdawes at, gregod at, cpdaniel at, john at