Boost logo

Boost-Build :

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-12-16 18:59:29


Those suffering from long build paths, I.E. all,

The long paths BBv2 produces has been a rather contentious subject in
the past. Everyone hates them, but no one has come up with a way to
reasonably make them shorter. Or as Volodya points out, most people want
them shorter but have no idea how :-)

Some context, this came about when I ran into the problem of features
with invalid filename chars in them end up in the build path. In
particular I'm in the middle of doing more changes to doxygen.jam and it
uses features of the form "doxygen:_x_". So I added a
"doxygen:processor" feature and immediately ran into directory creation
errors. Next I made the feature "implicit" which removed the
objectionable part but scrambled the path again as implicit features are
place first in the build path. So here's my latest idea...

First one would describe path shorthands for subsets of a property set.
We already do something similar in the conditionals. For example:

* Shortening the above doxygen path:

   feature.path doxproc : <doxygen:processor>doxproc ;
   feature.path doxslt : <doxygen:processor>xsltproc ;

* Shortening what is a regular longer build combination:

   feature.path static-mt :
     <link>static <threading>multi ;
   feature.path dynamic-mt :
     <link>dynamic <threading>multi ;
   feature.path vc8 :
     <toolset>msvc-8.0 ;

Which might produce the following paths:

   bin/libs/filesystem/build/vc8/debug/static-mt
   bin/libs/filesystem/build/vc8/debug/dynamic-mt
   bin/libs/filesystem/build/vc8/release/static-mt
   bin/libs/filesystem/build/vc8/release/dynamic-mt

Instead of the current:

   bin/libs/filesystem/build/msvc-8.0/debug/link-static/threading-multi
   bin/libs/filesystem/build/msvc-8.0/debug/threading-multi
   bin/libs/filesystem/build/msvc-8.0/release/link-static/threading-multi
   bin/libs/filesystem/build/msvc-8.0/release/threading-multi

The general form would be:

   feature /dir-name/ : /requirements/ ;

And of course users would be able to produce a single path for a
complicated build:

   feature.path my-build :
     <link>dynamic <threading>multi <toolset>msvc-8.0 #...etc.
     ;

The path generation algorithm would, given the build properties, go
something like:

1. start with an empty build path
2. for each registered feature path:
    a. if the feature path requirements match a subset of the build
properties, remove those properties and add the path to the build path
3. trim the redundant properties
4. split the properties into incidental and non-incidental
5. translate the incidental properties onto the front of the build path
6. translate the non-incidental properties onto the back of the build path
7. generate the final build path from the components

The effect is that the path is compressed based on the defined shorthand
paths plus any additional specific build properties. The one requirement
  would be that the feature paths would need to be unique. But that is
something easily checked and an error generated. The overall form of the
build paths would then be:

   bin /incidental parts/ ... /shorthands/ ... /non-incidental parts/

Thoughts?

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

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