"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87lkleyww8.fsf@pereiro.luannocracy.com...
You can review the guide at http://www.boost-consulting.com/boost/more/getting_started.html.
4. The only Boost libraries that can't be used without separate compilation are ... Boost.Test
Thanks for looking at this, Gennadiy,
This is not exactly true for Boost.Test. Boost.Test supplies inline versions for all components. This need to be somehow reflected to avoid confusion.
So Boost.Test *doesn't* require separate compilation? If that's the case, I'll remove it from the list and add a mention of it to the paragraph at the bottom of the box
Also since you put a link on Boost.Python, I think we need to set the link for each library in the list that refer to the compilation page/description for appropriate library
That's a good idea. The Boost.Python link currently just refers to its front page... ...On second thought, I'm not sure. I don't want to flood people with information or lead them to believe that they need to read all those pages before they can build the Boost libraries. Maybe I should just remove the link from Boost.Python. What about that?
7. ... Boost.Python users should read that library's own build documentation as there are several library-specific issues to consider
I understand that you are best familiar with your own library, but I believe this statement needs to be made generic.
I don't believe so. The case of Boost.Python is an outlier: a. There is a very strange thing that happens with build variants b. Using the static library will in most cases cost functionality and c. Unlike all other Boost libraries, auto-link chooses the dynamic library by default. That said, by the same logic I used above, I could remove that note. It's not needed in order to complete the tutorial.
The same could be said about Boost.Test and am sure other libraries have their quirks.If in addition to the genric statrment we add links to build doc for each standalone lib as I suggested above it should be good enough.
I'm very concerned about adding needless complication to this introductory document. Maybe in the section 8 that would be an appropriate place for links to library-specific build/configuration documentation.
7.3 Library naming ...
-vc71 Toolset tag: identifies the toolset and version used to build the binary.
Do I understand correctly that you streamlined names for msvc based toolsets?
I don't know what you mean. I didn't streamline anything.
Doesn't toolset tag here should refer to msvc either?
Sorry, I don't understand.
9. Appendix...
In several places this appendix sounds kinda silly, like you are writing it for the 6 year old computer novice, and not a computer programmer IMO. The same "press Return key" could be recommended for linux user either isn't it?
From reading user comments over the years I was given to believe that there's a community of GUI-only Windows users for whom command-line tools are utterly foreign; this section was designed to serve them. That said, I have no way of knowing what the appropriate level of detail is for those people. If this group is sure I've aimed at an inappropriate level, I'm happy to change it. Let's see what others think.
-- Dave Abrahams Boost Consulting www.boost-consulting.com