Re: [Boost-build] Shortening target paths

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.

Hi,

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.

unit-test blah
    : [ 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
            ;

or even:

copy-file c : <source>[ target mylib.a : <variant>release ] 
              <destination>/usr/lib
            ;

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.

Best Regards,
Matthew

-- 
Matthew Herrmann
matthew.herrmann_at_[hidden]
Vice President, Software Architecture
Zomojo Pty Ltd