Rene Rivera <grafik.list@redshift-software.com> writes:
David Abrahams wrote:
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
"Hendrik Schober" <SpamTrap@gmx.de> 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