From: Matthew Herrmann (matthew.herrmann_at_[hidden])
Date: 2006-04-10 19:29:30
> Vladimir Prus <ghost_at_[hidden]> writes:
> > On Monday 10 April 2006 15:52, David Abrahams wrote:
> >> Rene Rivera <grafik.list_at_[hidden]> writes:
> >> > * Write a HASH builtin:
> >> >
> >> > rule HASH ( string : hash-method ? )
> >> >
> >> > That of course requires finding free code for at least one good hash
> >> > function.
> >> There's already a string hashing function built into the core of
> >> bjam... so if it isn't good enough, I suppose we could just upgrade
> >> it.
> > Yes, it's MD5, I believe. Speaking of hashing paths, I doubt it's a good
> > solution. From user's perspective, long paths are just inconvenient, and
> > not many users have problems because command length limits. Using hashes
> > is just as inconvenient as long paths, IMO, because in both cases object
> > files end up in directories with "funny names". Ideally, we need to
> > create just "debug" directory for common cases.
> I agree that it would be ideal.
I don't have any particular objection to the length of paths, providing there
is an easy way to get at files within the structure. Having a
randomly-generated path would make that impossible except from within
Boost.Build, and exclude scripts from wrapping up these paths.
A use case for inexperienced users of Boost.Build such as myself that would
need to be satisfied for introducing the path hashing process is how to copy
a file from the target directory structure to another location. I know this
can be done with the install rule, but this does not always work. In
particular, unit test cases generate results rather than exe files as their
output, so the effect is not what one wanted.
: [ glob *.cpp ]
install other : blah ; # won't work, copies in test results instead
Without looking up what commands and syntax are available, (air code follows),
I'd like to be able to do something like this, which would
copy ./bin/gcc/debug/link-static/ :
copy-file c : <source>[ target mylib.a ] <destination>/usr/lib
copy-file c : <source>[ target mylib.a : <variant>release ]
which would keep the current gcc and link-static variations, but override
variant, in much the same way as we do for sources. In the above code, target
is intended to be a rule that takes in an orphan filename and optional tags,
and returns a fully-qualified path name. I guess such a function already
exists (since it must be used extensively throughout the BB source) but I
couldn't see it in the documentation.
-- Matthew Herrmann matthew.herrmann_at_[hidden] Vice President, Software Architecture Zomojo Pty Ltd
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