Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at