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