From: David Abrahams (dave_at_[hidden])
Date: 2005-05-26 10:11:34
"Peter" <pjfoley_at_[hidden]> writes:
> I have been reading this thread with interest.
> I thought I would throw my comments in regarding making the installation a
> little bit easier. Since I also had issues following the instructions.
> Message: 7
> Date: Wed, 25 May 2005 19:18:46 -0400
> From: David Abrahams <dave_at_[hidden]>
> Subject: [boost] Re: Customer Friendlier Boost Installation
> To: boost_at_[hidden]
> Message-ID: <ubr6y51yh.fsf_at_[hidden]>
> Content-Type: text/plain; charset=us-ascii
> Caleb Epstein <caleb.epstein_at_[hidden]> writes:
>> Admittedly there should be example command lines for vc-7_1 etc and
>> not just gcc.
> Can you suggest where we should show those examples? There are quite
> a few toolsets! Maybe in the table?
> Dave Abrahams
> Boost Consulting
> Hmm, is this a case of not seeing the forest because of the trees?
> Why use static content in this instance at all? If you really want to
> simplify it why not use some sort of applet?
Because we have an aversion to non-portable web constructs. It *is*
possible, given some restrictions. See http://tinyurl.com/6tdvy for
> We are programmers after all =p (well I am trying to be)
> Ie, on the Getting started page have a "Generate Bjam command line" link, on
> this page the user just selects:
> * Compiler (Drop down list)
> * Optional command line switches (Check boxes, with links to what each
> item does)
> - Optional path to Python if it is getting built
> * Path to extracted source of boost (Defaults to c:\Temp\Boost)
> * Path to compiled version of boost (Defaults to c:\Boost)
> User clicks on submit and it presents the correct command line
It's not a bad idea.
> User cuts and pastes this on a command prompt they hit enter and away they
> go. Obviously they still need to worry about the environment variables
> pointing to the compiler and linker and such.
> For bonus points extend bjam for "bjam -check_Env gcc". This will spit out
> an OK message listing the env variables it recognises.
> It will also spit out messages for env variables that it needs but
> cannot find.
> Ie, user would run "Bjam - check_env gcc" or "Bjam -check_env CW" and so on.
> (once again could be part of the generate bjam command line command weblink.
You can use, but don't need, any environment variables with
Boost.Build. In principle everything can be passed on the bjam
command-line with -s. Boost.Build was designed that way. I'd rather
not encourage people to use environment variables. Furthermore,
Boost.Build isn't in a position to check for the environment variables
used by various compilers. Normally Boost.Build has instructions for
setting those variables up before invoking the compilers
(e.g. cwenv.bat, vcvars32.bat), so if you pass the right Boost.Build
variables to let it know where the tools are, you don't have to worry
Maybe there's some corresponding thing you could check that has to do
with Boost.Build variables, but I'm not sure what it might be.
> This should also be fairly simple to maintain if the applet gets the
> compilers list (and env variables/or specific exe's it is looking
> for) from an easily updated list that can be updated as new compiler
> versions or differences come out.
> I guess the only thing stopping this is the capabilities of the web server
> and finding someone who is happy to extend Bjam and write the applet.
Are you volunteering?
> Then the process for install (with no other modifications would be):
> 1. Download boost source and extract
> 2. Download Bjam and extract
> 3. Run "Bjam - Check_Env" and fix any environment variable issues
> 4. Generate Bjam command line command from website (or from
> application?) and run it.
> 5. Update Include files path and lib file path in your favourite IDE,
> Make Files, ...
> Also keep the online documentation for those who are happy to learn about
> the intricacies of using Bjam.
> What do you think?
Are you volunteering? ;-)
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk