Boost logo

Boost-Build :

From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-06-26 16:46:39


> There are several factors affecting this:
> 1. Path constants are always in platform native format, i.e. your
> INSTALL_PATH variable holds the value '\speedo' instead of '/speedo'.

   This opens a question: Should the 'native' path on cygwin be
'/speedo'? I believe this could be a bug since the design choice seems
to have been to keep path constants in platform-native format and
cygwin's platform-native format is '/speedo'.

   Volodya? Any thoughts on this?

> 3. Something silently trims '\' characters from target names.

   Ok. 3 seems to be wrong. '\' characters remain the the target name
just fine as one can see by using the --debug-building option. You can
use such names to explicitly reference targets and Boost Build
recognizes them just fine.

   It is the install target that 'messes up' because it interprets the
target name as best as it can as the target location path but does so
expecting it to be in Boost Build's internal path format. Since it is
not, the effects are 'undefined'. In this case it loses the leading
backslash because it considers this path not to be absolute and makes a
'best effort' to concatenate it to the current project path, removing
any duplicate slashes & backslashes in the process.

   So you could also work around the original problem by using the

path-constant INSTALL_PATH : /speedo ;
local internal-install-path = [ path.make $(INSTALL_PATH) ] ;
install $(internal-install-path)/bin : speedoclt ;

   Not really sure what a 'clean' solution is here. If it were up to me
personally, I would consistently keep all paths in Boost Build's
internal path format and:
   - expect them to be specified that way inside Jamfiles
   - expect them to be specified on the command line in the native format
   - add a syntax for explicitly specifying them in the internal format
on the command line
   - expect Jamfiles to explicitly convert them to native format before
passing them to external tools.

   As I see it the current compromise reduces the amount of work one has
to do in the 'typical use cases' but at the cost of creating confusing
situations like this.

   Anyone have a suggestion for a 'better solution'?

   Best regards,
     Jurko Gospodnetić

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at