|
Boost : |
Subject: Re: [boost] [guideline] 31 character filenames?
From: Daniel James (dnljms_at_[hidden])
Date: 2012-03-27 18:58:44
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk