Re: Removing dots from toolset names
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
At 11:35 AM 10/6/2004, Aleksey Gurtovoy wrote:
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.
In addition to ISO 9660, the classic MAC OS, VMS, and various IBM legacy OS's were considerations. The classic MAC OS is less of a consideration today, and VMS also falls in that category. The legacy IBM systems are still important in some quarters, but we have never had any requests for Boost interoperability on those systems that I'm aware of. That pretty much leaves ISO 9660 as the main consideration. I'm under the impression that Joliet extensions are now widely available, although I've not done a systematic survey. --Beman
Beman Dawes wrote: <snip>
In addition to ISO 9660, the classic MAC OS, VMS, and various IBM legacy OS's were considerations.
The classic MAC OS is less of a consideration today, and VMS also falls in that category. The legacy IBM systems are still important in some quarters, but we have never had any requests for Boost interoperability on those systems that I'm aware of.
That pretty much leaves ISO 9660 as the main consideration. I'm under the impression that Joliet extensions are now widely available, although I've not done a systematic survey.
What if someone ports Boost to AmigaOS? That has a 30-character limit on filenames (in the standard filesystem, though not in all). I believe GCC 3.4 can still target AmigaOS, so this is not totally impossible... though not very likely to happen. Ben.
Beman Dawes writes:
At 11:35 AM 10/6/2004, Aleksey Gurtovoy wrote:
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.
In addition to ISO 9660, the classic MAC OS, VMS, and various IBM legacy OS's were considerations.
Thanks for the clarification.
The classic MAC OS is less of a consideration today, and VMS also falls in that category. The legacy IBM systems are still important in some quarters, but we have never had any requests for Boost interoperability on those systems that I'm aware of.
That pretty much leaves ISO 9660 as the main consideration. I'm under the impression that Joliet extensions are now widely available, although I've not done a systematic survey.
On major modern platforms, they are -- http://en.wikipedia.org/wiki/ISO_9660#Operating_system_support. -- Aleksey Gurtovoy MetaCommunications Engineering
participants (6)
-
Aleksey Gurtovoy -
Beman Dawes -
Ben Hutchings