[boost] Re: Customer Friendlier Boost Installation

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-05-26 10:48:09

David Abrahams wrote:
> "Hendrik Schober" <SpamTrap_at_[hidden]> writes:
> 
>>David Abrahams <dave_at_[hidden]> wrote:
>>
>>>"Hendrik Schober" <SpamTrap_at_[hidden]> writes:
>>>[...]
>>>
>>>>  OK, so I went to the that guide, downloaded boost
>>>>  1.32, downloaded bjam.exe, unzipped everything,
>>>>  and typed, IMHO according to the guide,
>>>
>>>>    C:\Temp\Download\boost\boost_1_32_0>..\bjam.exe bjam "-sTOOLS=VC71_ROOT" stage
>>>
>>>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>Surely you didn't type any of that stuff?
>>
>>  Actually, I really typed "..\bjam.exe" as this was
>>  where I put my copy of bjam. (I'm not editing my
>>  path env variable just for trying out a lib that I
>>  downloaded.) The prompt was provided by the system
>>  and the rest I just pasted.
> 
> 
> Heh.  Maybe we should write bjam in a different color so you're more
> likely to notice the difference between it and the rest of the
> command-line?

Or we can have a more explicit example, i.e.:

    C:\boost-1_32_0>bjam.exe "-sTOOLS=vc-7_1" stage

The idea being to show the context of the shell to make it clear that 
"bjam.exe" is the program name. Unix people are familiar enough with 
Windows to understand the above also.

>>>>  Right after that, it emitted
>>>>    don't know how to make -sTOOLS=VC71_ROOT
>>>
>>>bjam has this (silly, IMO) restriction -- inherited from jam --
>>>that options must precede targets on the command-line.  You are the
>>>victim of that, combined with the fact that you added an extra
>>>"bjam" which was interpreted as a target.  Therefore,
>>>-sTOOLS=VC71_ROOT was interpreted as a target.
>>
>>  I see. Mea culpa.
> 
> Well, jamma culpa too.  And bjamma culpa for not fixing that
> restriction.  It makes it hard for us every time we have to tell
> people to add some special bjam option to the command-line.  The ones
> beginning with a single "-" (and only those) need to come first.
> Dumb, dumb, dumb.

Well I guess this is as good a time as any to fix that silly limitation.

>>>But where did you get the idea that VC71_ROOT was a legal toolset
>>>name?
>>
>>  As I said elsewhere: Trying to read too fast.
>>  There was this table saying something that I
>>  interpreted as "click on your compiler's name
>>  to get what you'll need further down", there
>>  was some variable to be found there, elsewhere
>>  one was needed.
> 
> 
> Okay, maybe we should put "quick boost install instructions" in a box
> at the top of every toolset description page.

Possibly.. But ouch.. That's going to be an upkeep nightmare. Keeping 
the instructions consistent in the long run will be hard.

>>>>  Why wouldn't it find 2 of them?
>>
>>  I'm still amazed by this, BTW.
> 
> I don't know, offhand.  There are diagnostic options in bjam that
> allow us to find out, but you don't really care, do you?  That's why I
> think we should disable those messages.

It's the two targets typed in the command line itself, i.e. the "bjam" 
and "-sTOOLS=VC1..".

>>  Maybe I should just have used the installer and
>>  be done with this. 
> 
> Yes.

Perhaps the example should be "install" not "stage"?

>>  So either the different levels should be easier
>>  to tell from each other (maybe add a numbering
>>  scheme) or the page should be broken into several
>>  pages, so that I realize when I enter the next
>>  main section.
> 
> Very good suggestion.

Agreed.. Not sure I have the time for doing that now though. So help 
will be much appreciated :-)

>>  And please make the relationship between the
>>  headers and the numbering of (what I believe to
>>  be) the steps clear. I still don't know what
>>  this means.
> 
> Yeah.
> 
>>  IMO Supplemental information(like what to do
>>  with .zip/.tar files etc.) shouldn't interupt
>>  the reading. Most people know how to deal with
>>  compressed files on their platform, so a footnote
>>  leading to more info would do. 
> 
> 
> Good idea.

Perhaps the style of a single page per step. With the short version of 
what to do right at the top. And with the detail explanatory version at 
the bottom, like a footnote.

>>  One more thing: We have boost checked in into our
>>  CVS repository. We export it into every project it
>>  is used in, using the version tag specified in this
>>  project's checkout script. This allows using
>>  different boost versions in different projects,
>>  without requiring all developers to have the right
>>  versions in a specific folder on their machine.
>>  If we're going to use boost libs that require
>>  linking, I don't see how Boost.Build would fit into
>>  this scheme.
> 
> I think Rene can answer that; I know it's something we've addressed
> and that works.

Strangely I'm not sure what the question is :-)

One way is to "bjam ... stage" one each version of Boost and add the 
"stage" directory to the LIB search path of the compiler, and add the 
contents to your source control. This way you only build the libs once.

Another is to not use bjam at all, and just add the sources of the 
libraries you are using to the projects (or create sub-projects for them).

And another is to use bjam yourself in building you project, and Boost. 
In one of my projects I do a combination of this, and of the previous one.

And I've seen mentioned here before the option of running bjam from 
within the IDE when a library is needed.

HTH.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org