Re: Removing dots from toolset namesHo

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2004-10-08 15:43:49

Jürgen Hunold writes:
> On Wednesday 06 October 2004 17:35, Aleksey Gurtovoy wrote:
> > The changes are not that drastic, but it's a reasonable question to
> > ask. Ignoring the fact that we already have nonconforming names
> > fixing which requires some work, IMO all the current requirements
> > except 31-character limit are not hindering us in any significant
> > way, are easy to satisfy, and in general have a good cost/benefit
> > ratio.
> >
> > I don't feel strongly about maximum length of 31, in particular since
> > MacOS 9 is pretty much dead, and we _are_ somewhat restrained by the
> > limit. Being able to read a Boost CD on, let's say, Linux versions
> > released before 1999 is definitely going to be appreciated by
> > _somebody_, but there is a certain cost to that, and personally I'm
> > starting to feel that may be it's not worth it. But then, as a
> > release manager who has to take care of this issue, I'm biased.
>
> I've got this impression, too.
>
> My old PPC-6100-Mac is rotting in a corner ... ;-(((
>
> I don't want to spoil the release, but did you take a look at the
> BoostBook generated docs ?
> At least BBv2 generates files like
> "bbv2.reference.buildprocess.alternatives.html"

Yep, I'm aware of the issue. Or, rather, I was aware. It's taken care of
now -- http://article.gmane.org/gmane.comp.lib.boost.documentation/661.

> This will not work when someone tries to ship pre-built documentation on
> pure ISO-9660 CD, either.
> And I thought that a release tarball should contain a pre-built
> documentation because no-one can be expected to install all the
> necessary components to build it.

Yep, it should and it will.

> Do you/we want to change this, too ?
> And have *lots* of cryptic, human-unreadable file names ?

Well, the name length is still partly an issue, but certainly not to the
extent it was before the subdirectories fix. And even the overly long
names don't necessarily have to be turned into cryptic ids. For instance,
something like "static_local_time_adjustor.html" doesn't have to become
"id413791.html"; it can be "static_local_time_adjust00.html", or
"static_local_time_00.html", or something else along these lines.

Having said that, I'm going to repeat myself -- while I think all other
requirements are worth sticking to, I don't feel strongly about keeping
the 31-character limit. But now that we have not that many names to fix,
it's tempting to go with it to the end at least for this release.

> When we discuss this further, we should do it on Boost-Mailing-List

Transferred; Cc'd to jamboost.

--
Aleksey Gurtovoy
MetaCommunications Engineering