Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-12-12 08:28:54


"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:87lkleyww8.fsf_at_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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk