Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-24 14:22:15


"Paul A Bristow" <pbristow_at_[hidden]> writes:

> For years I have used Boost by simply adding the location of the unpacked
> release zip to the MSVC include path
>
> And I intend to do this more smartly as Victor Wagner suggest:
>
> "in addition, you can permanently put the boost library (and include)
> directories in ALL projects for Visual Studio by going to
> Tools->Options..projects..VC++ Directories.
> I've added:
>
> $(boost_root)\include\boost-$(boost_version)
> to the include directories and:
> $(boost_root)\lib
> to the library directories.
>
> maintaining the two environment variables is quite easy and causes barely a
> ripple when boost is upgraded.
> "
>
> (though I am unclear, as yet, what BOOST_ROOT is, and how it differs from
> boost_1_32_0).

BOOST_ROOT is just a placeholder for whatever the root directory of
your boost installation is. For boost 1.32 it's some path ending in
/boost_1_32_0.

> (As an aside MS have for VC Express (incredibly) made it more
> complicated by leaving out the tool, command, options, project
> directories, Include direcorites feature that made this possible, so
> now you have to do a lot of messing about to change them. Details
> on the MS forum or if anyone asks.
>
> And I have hand built the Boost test library and used it OK, copying the
> debug and release .lib files to the MSVC .lib directory.
>
> Being a simple chap, I previously thought the bjam method looked a bit too
> complicated, and I have recently been proved correct :-((
>
> I'm sure Python is most valuable but my disk and my brain are full, and I
> would prefer to avoid using them if possible.
>
> The instructions on the Boost .\boost\tools\build site are far too Unix and
> command line orientated for anyone who has degenerated to using the IDE
> exclusively (or has never learn how).

So far this is reading just like a litany of complaints.
Where, specifically, do you run into trouble?

> The instructions for Visual C++ Users on the WIKI are MUCH better
> for Windows folk, but are MSVC version specific (and in my view
> misguided in copying vast number of Boost files to the platform SDK
> rather than simply adding Boost to the include path to MSVC).

Is there a suggestion that goes with all this? Or a question we can
help you with?

You know that you can edit the WIKI yourself, don't you?

> It would also be sensible I believe to advise users to run bjam
> output to a log file
>
> bjam install > bjam.log
>
> except that if things go wrong (they did for me) you get :
>
> "The system cannot find the path specified."
>
> very many times, with no clues what path, on the screen, not the log
> file.

So then it's not very sensible advice, is it? You get a better sense
of what's happening when the stdout and stderr are properly
interleaved.

> One thing that is wrong is the directory for the compiler, so I used
>
> I:\boost_1_32_0>bjam.exe "-sVC71_ROOT=C:\Program Files\Microsoft Visual
> Studio 8
> \VC" install > bjam.log

Well you should be using the VC-8_0 toolset from Boost's CVS, which
uses the correct directory automatically.

> (and made environment TOOLS = MSVC =
> and tried -sTOOLS="C:\Program Files\Microsoft Visual Studio 8\vc"

What gave you the impression that

MSVC

or

"C:\Program Files\Microsoft Visual Studio 8\vc"

were valid values for the TOOLS variable?

> "C:\Program Files\Microsoft Visual Studio\VC98\bin\cl" is wrong
>
> and also
>
> CALL "C:\Program Files\Microsoft Visual Studio\VC98\bin\VCVARS32.BAT" d
> no longer exists - is C:\Program Files\Microsoft Visual Studio
> 8\VC\vcvarsall.bat ???
>
> I am sure the changes needed are obvious to those familiar with the
> bjam system, but to serve the Microsoft VC++ users (potentially very
> many, like it or not) it has to work 'out-of-the-box' much better
> than this - and be much better documented how to use it.
>
> Hopefully this can be improved for 1.33?

Have you tried the CVS?

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

Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk