From: Rene Rivera (grafik.list_at_[hidden])
Date: 2006-04-09 23:07:04
Vladimir Prus wrote:
> 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
> 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
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
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