Re: [Boost-build] Shortening target paths

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-04-10 11:40:40

On Monday 10 April 2006 19:32, Rene Rivera wrote:
> Vladimir Prus wrote:
> > 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.
>
> The only hash function I know of in bjam is for the string symbol table.
> And it not MD5. Upgrading it is also not an option as it's integral to
> the functioning of the hash table, meaning it's properties are designed
> for that use only. Exposing it is also not an option as it's has a high
> collision rate, relative to message digest hash functions.

Hmm.. I recall I saw MD5 builtin somewhere. Maybe that was some of 10 other 
jam variants, though.

>
> > 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.
>
> It will become a problem for a good number of users, those that use
> MinGW or Cygwin, when they start using anything but the builtin
> variants. For users, including myself as I ran into the problem while
> using BB, there's a limit as to how short one can make the target paths
> using variants and still maintain cross-platform/cross-compiler jamfiles.
>
> > Using hashes is just
> > as inconvenient as long paths, IMO, because in both cases object files
> > end up in directories with "funny names".
>
> Yes exactly! They are just as inconvenient, which I mentioned initially,
> but they are guaranteed to be short. I'll take the option that works
> 100% of the time over the one that works 75% of the time when they are
> otherwise equivalent.
>
> > Ideally, we need to create just "debug"
> > directory for common cases.
>
> Sure... but how to do that and still maintain independent builds? I
> haven't though about any automatic way of doing this. I can only think
> of the manual way of specifying target build paths. For example if
> variants could be selected based on requirements:
>
> variant debug-x86-win32 : debug
>    # properties
>
>    : <include>/special/x86 #etc...
>
>    # requirements
>
>    : <architecture>x86 <target-os>NT
>
> ;
>
> So that "debug-x86-win32" is selected when one asks for the "debug"
> variant. Hence putting the responsibility of deciding what is a unique
> build path on the users.

One approach is maybe remove the "symmetric" attribute from all features (so 
they don't show in path when they have default value, and allow each project 
to cleanly specify default values to itself. It's possible now by calling 
feature.set-default, but if two projects try to do this at the same time, 
results can be pretty confusing.

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2