"Peter" <pjfoley@bigpond.com> writes:

[De-Cloak]

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@boost-consulting.com> Subject: [boost] Re: Customer Friendlier Boost Installation To: boost@lists.boost.org Message-ID: <ubr6y51yh.fsf@boost-consulting.com> Content-Type: text/plain; charset=us-ascii Caleb Epstein <caleb.epstein@gmail.com> 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 www.boost-consulting.com

------------------------------

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

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

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