Eric Niebler <eric <at> boostpro.com> writes:
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"?
[1] http://www.boost.org/development/requirements.html [2] https://svn.boost.org/trac/boost/ticket/6196
Hello, I'm the one who filed the bug. I agree that ODS-2 is a niche filesystem also because it already has the successor ODS-5. ODS-5 supports longer filenames. Sadly, changeover to ODS-5 is still on the todo-list in our company. Anyway, here are my arguments for limiting the filename length to 39 (or less) characters: 1. The file for the bug in question was the only header file in the huge boost project which was longer than 39 characters. It is now shortened, so all header files are OK for ODS-2. So there is only an effort in checking new or changed files to obey the rules. (I didn't check other files than header files). 2. There are still many people who like there source code lines to be shorter than 80 characters. Longer filenames will lead to longer include directives. It would be no problem for me if the documentation files would be too long. Working with a niche OS, I'm already happy if a third party software compiles out of the box. Best regards, Christian