Re: [Boost-build] constant-path and install rule in Cygwin

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

   Hi

>   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 
following:

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ć