Re: [jamboost] Target path length

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-16 10:26:46

Hi Thomas,

I have a number of ideas about this, but no perfect solution:

1. First there's a LOT we could do right now to remove path elements from
the subvariant directories. For one thing I notice that properties which
are defined in the base variant often show up in the subvariant path. Also,
any properties which are in a target's requirements should be eliminated
from its subvariant path, since they're always present for that target.
Unfortunately, I don't really understand the code which generates these
paths well, anymore.

2. We could find some way to automatically abbreviate feature names when
they go into subvariant paths. I've used systems which pick a letter for
each property and form "mangled" single-level directory names corresponding
to each property set. So a debug build with optimization on might go into a
directory called "do". We could also pick unique abbreviations for each
property name by doing some regex magic, and just use the regular directory
hierarchy with the abbreviations. The biggest problem I can see with this
arrangement is that it not only requires that properties be unique (as we
do today) but also that the abbreviations be unique. That's OK as long as
all features are defined in a central location, but I don't expect that to
be the case. Even today we have some features defined in toolset files.
When you start abbreviating, the chance of collisions goes up. Something
needs to be able to see all the possible features and check/generate the
abbreviations so that they don't collide.

-Dave

----- Original Message -----
From: "Thomas Witt" <witt_at_[hidden]>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hi,
>
> I just spend the better part of today chasing a bug that turned out to be
a
> problem with target path length.
>
> Currently all features have long speaking names that are easy to read and
> remember. So far so good. As a result the target path get quite long as
well.
> This is especially a problem with the stlport toolsets.
>
> What happened to me was that I had a generated cpp file sitting in
> $(LOCATE_TARGET). This cpp file include a file from $(LOCATE_SOURCE),
using
> "#include "relative-path-here". On W2k both cl and icl complained that
they
> could not find the include file, when the target path exceeded a certain
> length. Yes I am quite certain that the problem is length and not depth.
>
> It seems like path length is still an isssue on W2k, so my question is:
> Shouldn't we try to use shorter feature names to avoid these problems?
E.g.
> stlport-iostreams -> stlp-ios and the like.
>
> Comments?