What should we do about the following Boost.Build toolsets which filename's length exceeds 31 characters: tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam ? -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
What should we do about the following Boost.Build toolsets which filename's length exceeds 31 characters:
tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam
?
Sorry to state the obvious, but... shorten the names? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
What should we do about the following Boost.Build toolsets which filename's length exceeds 31 characters:
tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam
?
Sorry to state the obvious, but... shorten the names?
How exactly? Every part of the name carries essential information that cannot be omitted without disabling other possible configurations. For example, the only way we could omit "vc6" in "intel-win32-7.1-vc6-stlport-4.5.3-tools" is if we explicitly decide that we don't care about, let's say, "intel-win32-7.1-vc7-stlport-4.5.3-tools", and nobody ever will. ^^^ And so on. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
What should we do about the following Boost.Build toolsets which filename's length exceeds 31 characters:
tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam
?
Sorry to state the obvious, but... shorten the names?
How exactly? Every part of the name carries essential information that cannot be omitted without disabling other possible configurations. For example, the only way we could omit "vc6" in "intel-win32-7.1-vc6-stlport-4.5.3-tools" is if we explicitly decide that we don't care about, let's say, "intel-win32-7.1-vc7-stlport-4.5.3-tools", and nobody ever will. ^^^ And so on.
icl7.1-vc6-stlp453-tools?
Peter Dimov wrote:
Aleksey Gurtovoy wrote:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
What should we do about the following Boost.Build toolsets which filename's length exceeds 31 characters:
tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam
?
How exactly? Every part of the name carries essential information that cannot be omitted without disabling other possible configurations. For example, the only way we could omit "vc6" in "intel-win32-7.1-vc6-stlport-4.5.3-tools" is if we explicitly decide that we don't care about, let's say, "intel-win32-7.1-vc7-stlport-4.5.3-tools", and nobody ever will. ^^^ And so on.
icl7.1-vc6-stlp453-tools?
You have to be carefull when changing the name. As the variant names for build+install require the toolset names to be in a perticular form. So you either update the common-variant-tag rule to account for your changes. Or you need to follow some rules: * You can use the short name or the long name of the toolset. For example you can use either "intel-win32" or "iw". * You need the version of the toolset to include both major and minor numbers separated by a period. No need for patch numbers. So here you have to keep the "7.1". * You need to keep "stlport" in the name. [This would be an easy one to change to recognize a shorter synonym] * You need to keep the basic format of: <name>-<version>...stlport...-tools.jam Even with that boost-base.jam will need to change to handle both "intel-win32" and "iw". You can probably shorted "vc6" to just "6", assuming that VC is the only supported backend for the toolset. So the shortest I would suggest is: iw-7.1-6-stlport453-tools.jam Which comes in at 29 chars. You could even add back in the "vc" and still be at 31 chars :-) --grafik
Rene Rivera writes:
You have to be carefull when changing the name. As the variant names for build+install require the toolset names to be in a perticular form. So you either update the common-variant-tag rule to account for your changes. Or you need to follow some rules:
* You can use the short name or the long name of the toolset. For example you can use either "intel-win32" or "iw".
OK, let's go with "iw", then.
* You need the version of the toolset to include both major and minor numbers separated by a period. No need for patch numbers. So here you have to keep the "7.1".
OK.
* You need to keep "stlport" in the name. [This would be an easy one to change to recognize a shorter synonym]
Can we have "stlp" as a synonym, then?
* You need to keep the basic format of: <name>-<version>...stlport...-tools.jam
Even with that boost-base.jam will need to change to handle both "intel-win32" and "iw".
Here, I suppose: switch $(toolset) { case borland* : toolset-tag += bcb ; case como* : toolset-tag += como ; case cwpro8* : toolset-tag += cw 8 ; case cwpro9* : toolset-tag += cw 9 ; case darwin* : toolset-tag += ; case edg* : toolset-tag += edg ; case gcc* : toolset-tag += gcc ; case intel-linux* : toolset-tag += il ; case intel-win32* : toolset-tag += iw ; ... ?
You can probably shorted "vc6" to just "6", assuming that VC is the only supported backend for the toolset.
So the shortest I would suggest is:
iw-7.1-6-stlport453-tools.jam
Which comes in at 29 chars. You could even add back in the "vc" and still be at 31 chars :-)
OK, sounds good enough. What about "como-win32-4.3.3-vc7.1-tools.jam"? Does renaming it to something like "comow-4.3.3-vc7.1-tools.jam" requires some tweaks to other parts of the Boost.Build as well? Thanks for the assistance, -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Rene Rivera writes:
* You need to keep "stlport" in the name. [This would be an easy one to change to recognize a shorter synonym]
Can we have "stlp" as a synonym, then?
Sure... I'll make the change.
* You need to keep the basic format of: <name>-<version>...stlport...-tools.jam
Even with that boost-base.jam will need to change to handle both "intel-win32" and "iw".
Here, I suppose:
case intel-linux* : toolset-tag += il ; case intel-win32* : toolset-tag += iw ;
No. The "case *" part handles the generic case of using the short "iw" name: case * : toolset-tag += [ MATCH "^([^-]*)" : $(toolset) ] ; It's this part further down in toolset::requirements rule: case intel-win32* : { # dynamic runtime only comes in the multi-threading flavor if <runtime-link>dynamic in $(properties) { requirements += <threading>multi ; } }
OK, sounds good enough. What about "como-win32-4.3.3-vc7.1-tools.jam"? Does renaming it to something like "comow-4.3.3-vc7.1-tools.jam" requires some tweaks to other parts of the Boost.Build as well?
Yes that name would work without changes. I'll make the changes now... OK done. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
From: "Peter Dimov" <pdimov@mmltd.net>
Aleksey Gurtovoy wrote:
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
What should we do about the following Boost.Build toolsets which filename's length exceeds 31 characters:
tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam
Sorry to state the obvious, but... shorten the names?
How exactly? Every part of the name carries essential information that cannot be omitted without disabling other possible configurations. For example, the only way we could omit "vc6" in "intel-win32-7.1-vc6-stlport-4.5.3-tools" is if we explicitly decide that we don't care about, let's say, "intel-win32-7.1-vc7-stlport-4.5.3-tools", and nobody ever will. ^^^ And so on.
icl7.1-vc6-stlp453-tools?
No matter how you compress things, won't there be combinations that exceed the character limit? We can deal with that when it happens, of course, but I was thinking that there can be a dictionary file that maps from the long, complex set of discriminators to a short name. Then, even if you don't recognize a particular toolset name, you can look it up in the dictionary file to learn what it means. Creating new entries is simply a matter of encoding all of the relevant details and picking a short name that is unique and, whenever possible, has some mnemonic correlation to the details. Duplicate names are possible if folks aren't careful; the scanning tools could look for and complain about that condition. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> writes:
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
What should we do about the following Boost.Build toolsets which filename's length exceeds 31 characters:
tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam
?
Sorry to state the obvious, but... shorten the names?
How exactly? Every part of the name carries essential information that cannot be omitted without disabling other possible configurations.
Simple; we just change the build/test system to allow the abstract toolset name to differ from the filename. The file could contain the actual toolset name if neccessary: icl-7.1-vc6-stlport-4.5.3-tools.jam: toolset-name intel-win32-7.1-vc6-stlport-4.5.3 ; extends-toolset intel-win32 ; ... -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams writes:
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> writes:
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
What should we do about the following Boost.Build toolsets which filename's length exceeds 31 characters:
tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam
?
Sorry to state the obvious, but... shorten the names?
How exactly? Every part of the name carries essential information that cannot be omitted without disabling other possible configurations.
Simple; we just change the build/test system to allow the abstract toolset name to differ from the filename. The file could contain the actual toolset name if neccessary:
icl-7.1-vc6-stlport-4.5.3-tools.jam:
toolset-name intel-win32-7.1-vc6-stlport-4.5.3 ; extends-toolset intel-win32 ; ...
I like it. If we can have this sometime soon, it's going to save me some (minor) work on adjusting expected results/explicit failures markup to reflect the new names. If not, though, I'll go with what Rene and I have worked out. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
David Abrahams writes:
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> writes:
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
What should we do about the following Boost.Build toolsets which filename's length exceeds 31 characters:
tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam
?
Sorry to state the obvious, but... shorten the names?
How exactly? Every part of the name carries essential information that cannot be omitted without disabling other possible configurations.
Simple; we just change the build/test system to allow the abstract toolset name to differ from the filename. The file could contain the actual toolset name if neccessary:
icl-7.1-vc6-stlport-4.5.3-tools.jam:
toolset-name intel-win32-7.1-vc6-stlport-4.5.3 ; extends-toolset intel-win32 ; ...
I like it. If we can have this sometime soon, it's going to save me some (minor) work on adjusting expected results/explicit failures markup to reflect the new names. If not, though, I'll go with what Rene and I have worked out.
I don't know enough about where the test system gets the names it uses to make the modifications myself, if that's what you had in mind. Sorry, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"Aleksey Gurtovoy" wrote:
What should we do about the following Boost.Build toolsets which filename's length exceeds 31 characters:
tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam
While boost build file and directory names are really self-explanatory, it looks to me it is pushing it too far. I don't have a problem with the length of file names (even if some shortcuts, like I for intel, getting rid of dashes, and similar could help) but build directory hierarchy is really getting too deep, especially when you consider builds for various CRT linkage combinations. As far as MS VS IDE is concerned, build directory names like "debug runtime-static threading-multi" (with the space character) would make life easier than directory tree like the current "...debug/runtime-static/threading-multi" because the string "debug runtime-static threading-multi" can become $(ConfigurationName) macro in IDE. This would be more helpful if you generate project configurations from IDE but maybe also if you have some tool that automatically generates MS IDE vcproj XML. Tony
Tony Juricic wrote:
"Aleksey Gurtovoy" wrote:
What should we do about the following Boost.Build toolsets which filename's length exceeds 31 characters:
tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam
While boost build file and directory names are really self-explanatory, it looks to me it is pushing it too far. I don't have a problem with the length of file names (even if some shortcuts, like I for intel, getting rid of dashes, and similar could help) but build directory hierarchy is really getting too deep, especially when you consider builds for various CRT linkage combinations.
I was thinking that we can use the same scheme which is used for installed target naming for directories. E.g. a directory would be named gcc-mt-d instead of gcc/debug/threading=multi - Volodya
participants (7)
-
Aleksey Gurtovoy -
David Abrahams -
Peter Dimov -
Rene Rivera -
Rob Stewart -
Tony Juricic -
Vladimir Prus