[1.32 Release] Fixing long filenames
One thing that we really have to take care of before branching is long filenames. Could maintainers of the following libraries please fix the corresponding problems listed in detail in http://www.boost.org/regression-logs/inspection_report.html? archive (serialization) build date_time graph iterator preprocessor property_map python serialization spirit test utility/enable_if Thanks! -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
One thing that we really have to take care of before branching is long filenames. Could maintainers of the following libraries please fix the corresponding problems listed in detail in http://www.boost.org/regression-logs/inspection_report.html?
archive (serialization) build date_time graph iterator preprocessor property_map python serialization spirit
Fixed.
test utility/enable_if
Regards Hartmut
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
One thing that we really have to take care of before branching is long filenames. Could maintainers of the following libraries please fix the corresponding problems listed in detail in http://www.boost.org/regression-logs/inspection_report.html?
archive (serialization) build date_time graph iterator
Fixed.
preprocessor property_map python serialization spirit test utility/enable_if
Thanks!
-- Aleksey Gurtovoy MetaCommunications Engineering _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Mon, 13 Sep 2004 02:06:20 -0500, Aleksey Gurtovoy wrote
One thing that we really have to take care of before branching is long filenames. Could maintainers of the following libraries please fix the corresponding problems listed in detail in http://www.boost.org/regression-logs/inspection_report.html?
... date_time ...
Fixed. Jeff
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Aleksey Gurtovoy
One thing that we really have to take care of before branching is long filenames. Could maintainers of the following libraries please fix the corresponding problems listed in detail in http://www.boost.org/regression-logs/inspection_report.html?
preprocessor
libs/preprocessor/doc/blank.html: unlinked file
Fixed.
libs/preprocessor/doc/headers/enum_params_with_a_default.hpp.html: filename > 31 chars libs/preprocessor/doc/headers/enum_params_with_defaults.hpp.html: filename > 31 chars libs/preprocessor/doc/headers/repetition/enum_params_with_a_default.hpp.html: filename > 31 chars libs/preprocessor/doc/headers/repetition/enum_params_with_defaults.hpp.html: filename > 31 chars
libs/preprocessor/doc/headers/repetition/enum_trailing_binary_params.hpp.html: filename > 31 chars
libs/preprocessor/doc/ref/enum_trailing_binary_params.html: filename > 31 chars libs/preprocessor/doc/ref/enum_trailing_binary_params_z.html: filename > 31 chars
Fixed with comment. The 31+ filename limit breaks the naming convention where filenames mirror their contained facilities. This is particularly a problem with the pp-lib since there are no namespaces that can be mirrored with directory structure.
libs/preprocessor/doc/title.html: unlinked file libs/preprocessor/doc/top.html: unlinked file
These two are linked in a frameset.
libs/preprocessor/doc/topics/file_iteration.html: broken link: choosing_repetition.html libs/preprocessor/doc/topics/local_iteration.html: broken link: choosing_repetition.html
Fixed with note. These weren't broken links, they were referenced only within <!-- --> comments. Regards, Paul Mensonides
"Paul Mensonides" <pmenso57@comcast.net> writes:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Aleksey Gurtovoy
One thing that we really have to take care of before branching is long filenames. Could maintainers of the following libraries please fix the corresponding problems listed in detail in http://www.boost.org/regression-logs/inspection_report.html?
preprocessor
libs/preprocessor/doc/blank.html: unlinked file
Fixed.
libs/preprocessor/doc/headers/enum_params_with_a_default.hpp.html: filename > 31 chars libs/preprocessor/doc/headers/enum_params_with_defaults.hpp.html: filename > 31 chars libs/preprocessor/doc/headers/repetition/enum_params_with_a_default.hpp.html: filename > 31 chars libs/preprocessor/doc/headers/repetition/enum_params_with_defaults.hpp.html: filename > 31 chars
libs/preprocessor/doc/headers/repetition/enum_trailing_binary_params.hpp.html: filename > 31 chars
libs/preprocessor/doc/ref/enum_trailing_binary_params.html: filename > 31 chars libs/preprocessor/doc/ref/enum_trailing_binary_params_z.html: filename > 31 chars
Fixed with comment. The 31+ filename limit breaks the naming convention where filenames mirror their contained facilities. This is particularly a problem with the pp-lib since there are no namespaces that can be mirrored with directory structure.
Yeah, that's really a shame... oh, but these are all html files, no? If so I don't think that's so terrible. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams
Fixed with comment. The 31+ filename limit breaks the naming convention where filenames mirror their contained facilities. This is particularly a problem with the pp-lib since there are no namespaces that can be mirrored with directory structure.
Yeah, that's really a shame... oh, but these are all html files, no? If so I don't think that's so terrible.
It isn't the end of the world, no, but it is useful for navigating directly to a particular page in a rational fashion because of logical structure. Regards, Paul Mensonides
On 2004-09-13, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
One thing that we really have to take care of before branching is long filenames. Could maintainers of the following libraries please fix the corresponding problems listed in detail in http://www.boost.org/regression-logs/inspection_report.html?
That report doesn't seem to report pathnames (as opposed to filenames) that exceed tar's 100 character limit. This, if memory serves, caused grief in the previous release because GNU tar has a "workaround" to deal with it that causes some tar's to barf. (Don't forget to take account of the boost-1.32.0/ directory name, which takes 13 characters, leaving a mere 87...) Or is there an assumption that people all use one of the extended tar? phil -- change name before "@" to "phil" for email
participants (7)
-
Aleksey Gurtovoy -
David Abrahams -
Doug Gregor -
Hartmut Kaiser -
Jeff Garland -
Paul Mensonides -
Phil Richards