Re: [boost] [guideline] 31 character filenames?

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
James
> 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[1] say filenames should not exceed 31 characters.
> >>> This was recently brought to my attention by a bug[2] 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
have access
> 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
someone might
> need to build on such a platform, they can probably view the documentation elsewhere, or from the
web.
> 
> There's a bug in the code for truncating boostbook reference documentation which causes the
filenames
> to be a bit longer than it should be (quite telling that no one noticed in the years since I
implemented it).
> 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
its doxygen
> documentation.

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

---
Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
[phone]  07714330204
pbristow_at_[hidden]