Jürgen Hunold writes:
Hi !
Hi Jürgen,
On Tuesday 05 October 2004 15:10, Aleksey Gurtovoy wrote:
Hi All,
As you probably already know, we also need to take care of these:
Why ? Can someone point me to the rationale for this ?
The original rationale was "to ensure file and directory names are relatively portable": http://www.boost.org/more/lib_guide.htm#Directory_structure. Beman might be able to clarify whether ISO 9660/Level 2 requirements in particular were one of the motivating factors back then or not, but currently those are the primary driving force for getting Boost codebase to conform to these rules: We want to be able to put a Boost distribution on a CD in the unpacked form, and for that CD to be readable on the maximum number of platforms.
Where can I find out which platforms have which limits ?
WWW :). Here, for instance -- http://www.zplace.com/crashtips/filename.html.
intel-win32-7.1-vc6-stlport-4.5.3-tools.jam: filename > 31 chars, filename contains more than one dot character ('.') intel-win32-7.1-vc6-tools.jam:
Some of these toolsets exist in current 1.31.0 with _more_ than one dot. Take vc7.1-stlport-tools.jam for example.
Sure. The requirements weren't strictly inforced until now.
I suggest we either replace the dots with underscores, or get rid of them completely (besides the last one, of course), i.e. either:
borland-5_5_1-tools.jam borland-5_6_4-tools.jam como-win32-4_3_3-vc7-tools.jam
-1
borland-551-tools.jam borland-564-tools.jam como-win32-433-vc7-tools.jam ... Preferences?
+1
Thanks!
[I also know that there is more to this than just renaming of the files; any help with the whole matter would be greatly appreciated.]
Just one curious question: AFAIK, all of the platforms these toolsets are _for_ support both filenames with more than 31 characters and more than one dot. I just wonder if we should break and repair the whole V1 build system when the offending toolsets are for platforms which don't _have_ these limits.
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.
Just my .02€, developing on linux and win32.
Thanks, they are appreciated. -- Aleksey Gurtovoy MetaCommunications Engineering