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