Re: [Boost-build] Shortening target paths

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2006-04-09 23:07:04

Vladimir Prus wrote:
> Hello!
> 
> This is a call for help. At the moment, V2 (just like V1) tends to produce 
> pretty long target paths.

After being bitten by this problem yet again, after posting commentary 
<http://zigzag.cs.msu.su/boost.build/ticket/5> about it. I think at this 
point that...

> This issue has several components:
> 
>   1. We produce extra path element even for features not affecting particular
>      target. For example "debug" in target path for generated docs is wrong.
>   2. Using full names of features makes for pretty long paths, and there's no
>      "compression" of paths.
>   3. The algorithm to compute the path is completely non-customizable.
> 
> Those are problems, but really, I don't have completely answers to help. If 
> somebody could come and propose/design the right semantic of target paths, 
> this would be a great help.

Trying to optimize target paths in any meaningful way is a loosing 
battle. I favor going the "compression of path" direction. As I mention 
on that bug report compressing the target path with a hash function 
seems the easiest and most stable long term solution to the problem. The 
drawback of course is the reduced clarity that not having a readable 
path poses to users.

Change to get the functionality AFAICT:

* Write a HASH builtin:

     rule HASH ( string : hash-method ? )

That of course requires finding free code for at least one good hash 
function. Supporting multiple hash methods is important for back 
compatibility. If we decide that we want to change we wont be forcing 
people who only upgrade bjam to rebuild all their code. My preferred 
hash method for such things is MD4, because of quality comparable to MD5 
but with higher speed.

* Change the property.as-path to use the HASH of the all properties 
instead of trying to minimize. Is this the only point where the path is 
calculated?

One advantage to having a HASH builtin is that it allows us to 
eventually implement detection of changed build options by hashing the 
command invocation options. This would be similar to what Scons does, 
except that they hash entire files to detect changes, AFAIK.

And of course I'd be willing to implement this... Actually I would get 
someone else to do the hard parts, like getting the hash code written.

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