Subject: Re: [boost] [guideline] 31 character filenames?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2012-03-28 04:44:49
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of Daniel
> Sent: Tuesday, March 27, 2012 11:59 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] [guideline] 31 character filenames?
> On 27 March 2012 23:25, Eric Niebler <eric_at_[hidden]> wrote:
> > On 3/27/2012 2:22 PM, Daniel James wrote:
> >> On 27 March 2012 22:08, Eric Niebler <eric_at_[hidden]> wrote:
> >>> Our current guidelines say filenames should not exceed 31 characters.
> >>> This was recently brought to my attention by a bug from someone
> >>> who actually cares because he uses the ODS-2 filesystem on OpenVMS.
> >>> On a lark, I hacked the inspect tool to check for too-long filenames and lo!
> >>> found a bazillion. Most (but not all) violations are from doc files
> >>> auto-generated by doxygen and docbook, but which nevertheless go out
> >>> with the boost distribution and so should conform. (Right?)
> >>> So, should we care? Considering that we have little control(?) over
> >>> how doxygen and docbook generate their files? I have fixed the bug
> >>> in question, but it feels like a token effort. Should we just drop
> >>> support for niche filesystems like ODS-2, and close all future bugs "won't fix"?
> >> It is different for source and documentation files, because
> >> documentation files aren't going to break a build.
> > OK, is that the intent of the guideline? What happens when someone
> > tries to unpack the boost tarfile on a filesystem that doesn't support
> > long filenames? Are the doc files with long names silently dropped? Or
> > is it an error? Or...? :-/
> I can't comment on the guideline since it was written before I was involved with Boost. I don't
> to any platforms where this is an issue, but no one has ever reported any problems with the
> documentation. I think that's a pretty strong indicator that it isn't a major problem. While
> need to build on such a platform, they can probably view the documentation elsewhere, or from the
> There's a bug in the code for truncating boostbook reference documentation which causes the
> to be a bit longer than it should be (quite telling that no one noticed in the years since I
> I'm fixing that now, although I'm not sure how comprehensive it is, it certainly won't truncate
ids given by
> the user. Doxygen users might want to look at the script 'gil' uses to reduce the file length for
As I recall, the 31 char limit was because we wanted to be able to copy all the files on a CD.
I'm not sure this is still important (you'd probably zip anyway?), so I agree it should be dropped
as a requirement, and the bugs 'won't-fixed'.
I've had Doxygen generated filenames that were too long (for Windows?) and had to use the mechanism
provided to make them shorter, so I think we need to keep that (preferably bug-free ;-)
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow_at_[hidden]