[boost] Re: Customer Friendlier Boost Installation

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-26 11:05:09

Rene Rivera <grafik.list_at_[hidden]> writes:

> 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.

IMO there's no excuse for writing ".exe" there, and it will only make
it less easy for Unix people.  Make the prompt a different color and
then we have something that really is less likely to confuse anyone.

>>>>>  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.

Does that mean you're doing it?

>> 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.

Not really; we're retiring v1, remember?

>>>>>  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..".

Ah, light dawns :)

>>>  Maybe I should just have used the installer and
>>>  be done with this. 
>> Yes.
>
> Perhaps the example should be "install" not "stage"?

No opinion.

>>>  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
     ^^^^^^^^^^^^^^^^^^^^^^^^^
I missed that on first reading.

>>>  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 :-)
>

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com