Boost logo

Boost-Build :

Subject: [Boost-build] Help organizing Boost.Build project
From: AFoglia_at_[hidden]
Date: 2009-01-26 10:24:59


        We've been using Boost.Build on our project for over a year now, and
while I like it, I don't think we're using it properly for our code
layout. Our code is structured into two svn repositories roughly like
this :

repository1
   - trunk
       - lib
          - math
          - utilities
       - projects
          - proj1
          - proj2
   - Sandbox
       - user1
       - user2
       - user3

repository2
   - trunk
       - projA
       - projB
   - Sandbox
       - user1
       - user2

In repository 1, there are a few libraries used by multiple projects.
Currently, we have a Jamroot in repository1:trunk/ and another file
called sysdefs.jam for the system configuration. The latter defines
rules for the third-party libraries such as from Boost. The Jamroot has
use-project rules for each of the libraries in lib, for example :

use-project /proj-libs/utilities : lib/utilities ;

Roughly, each directory in projects is responsible for one executable
and has Jamfile typically of the form :

exe proj1
    : proj1.cpp
      /sysdefs//boost-program-options # and/or other third-party libs
      /proj-libs/utilities//utilities/
    ;

This works reasonably well when working solely in repository one's trunk.

Each user has a sandbox in the Sandbox directory. With no default
Jamroot above it, people have been doing different things:
User 1 checks out his Sandbox under trunk, so trunk's Jamroot is used
automatically.
User 2 checks out the sandboxes parallel to trunk and has written his
own custom Jamroot and sysdefs.jam which gets called when he compiles
within his sandbox. This configuration does not realize if the
libraries in trunk need to be recompiled.
User 3 also checks out the sandboxes parallel to trunk, but his custom
Jamroot imports the trunk's sysdef.jam.

In addition, there's a second repository which uses libraries from the
first. Most people check it out underneath where they've checked out
the trunk of repository 2. And like repository 1, people with access to
this repository have an additional sandbox in there as well.

Finally, we are not only in the process of changing the Linux
distribution of our main computers, but we're getting new ones as well.
  We have a big case statement in the sysdefs.jam to define where the
third-party libraries are on each system.

I'm certain there's a better way. How should we organize and write the
jam rules so that we can easily have people's checked out versions more
closely match the repository? Are there any tricks to transition our
code to it breaking as little as possible?

-- 
Anthony Foglia
Princeton Consultants

Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk