Customer Friendlier Boost Installation
Recently we had a flurry of discussion of why Boost is not more widely used. I have used some bits of Boost happily for years, but recently I felt I had to use it 'properly' so concluded it was time I used the bjam build system - something I had felt looked a bit clever. Indeed my suspicion was proved correct - I couldn't get it to work. The instructions are far too Unix/Make oriented for this mere Windows hacker; the Wiki Windows specific instructions are much better but suggest copying (duplicating) a lot of files to avoid an addition to the include directories, and don't apply to the most recent compilers. Victor Wagner gave some hints recently using environment variables, but not the full text. I don't doubt the usefulness of the bjam to the congescenti - only with this could the incredibly impressive build & test system allow all the cracks and chasms of compiler non-compliance and language imprecision to be papered over - Boost's great strength. But if we are to interest your average Windows IDE programmer, for whom MAKE is a blank or a distant nightmare, IMO we need some much better and simpler instructions, including lots of examples of input and output, and to be as well tested as the rest of Boost code. Like it or not, these are the potential customers and I spoken to many who are put off by the 'build barrier'. I suggest that we explicitly say that you can use all of Boost (except the ones that must have built libraries) by adding to the include list - and say exactly how in Windows IDE-ese. If you share my concern, would some someone like to prepare something? Or at least provide details of their way of doing it. I will be willing to help with checking/editing. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com
Paul A Bristow wrote:
If you share my concern, would some someone like to prepare something? Or at least provide details of their way of doing it. I will be willing to help with checking/editing.
I'd like to see IDE projects for bosot (e.g. BCB6, VS.Net etc). That would make things a lot, lot nicer. I did do this for C++BuilderX, but only for the specific parts I required, and not for all the possible combinations of static/dynamic runtimes, dlls/static libs, thread/non-threaded. I'll see if I can get something for BCB6 together, but I think it will take a while as fairly swamped at work at the moment. Thanks Russell
Russell Hind wrote:
Paul A Bristow wrote:
If you share my concern, would some someone like to prepare something? Or at least provide details of their way of doing it. I will be willing to help with checking/editing.
I'd like to see IDE projects for bosot (e.g. BCB6, VS.Net etc). That would make things a lot, lot nicer. I did do this for C++BuilderX, but only for the specific parts I required, and not for all the possible combinations of static/dynamic runtimes, dlls/static libs, thread/non-threaded.
I'll see if I can get something for BCB6 together, but I think it will take a while as fairly swamped at work at the moment.
What would be better is a way to auto-generate IDE projects from the jam files. That way you don't need to specify VC6, VC7, VC71, VC8, BCB5, BCB6, CodeWarrior, Eclipse, insert-your-favorite-IDE-here project files for all the examples, libraries, etc. Ideally, there should be a single program that could process jam files (an extension of bjam?) that can accept a template file that tells it how the project file(s) should be structured. This would then allow something like: genide libs/program_options/examples msvc-7.1 which would generate the project files for the specified project. Alternatively, there could be plugins written to hook into the various IDEs that will import a bjam project in a friendly GUI way. (This might call the command-line utility so people who prefer command-line or GUI can take their pick.) Perhapse what is also needed is a friendly GUI that allows you to configure bjam/BBv2 and create new projects. This infrastructure could hook into your favorite IDE (Eclipse, VS, BCB) so you could edit build and run the jam files from inside the IDE without touching the command line. This would go a long way to increasing the appeal of Boost to a RAD/GUI developer. It should also be possible to edit the project (jam) files directly and have control over their formatting. Summing up, there would be a GUI-based: * setup/configuration of Boost; * project creation wizards to create BBv2 projects; * conversion tool to convert to your favorite IDE format; * hook-ins to allow BBv2 projects to be managed in your favorite IDE. Reece Haston Dunn Software Engineer, Sophos Web: www.sophos.com Sophos - protecting businesses against viruses and spam
"Reece Dunn" <msclrhd@hotmail.com> writes:
Russell Hind wrote:
Paul A Bristow wrote:
If you share my concern, would some someone like to prepare something? Or at least provide details of their way of doing it. I will be willing to help with checking/editing.
I'd like to see IDE projects for bosot (e.g. BCB6, VS.Net etc). That would make things a lot, lot nicer. I did do this for C++BuilderX, but only for the specific parts I required, and not for all the possible combinations of static/dynamic runtimes, dlls/static libs, thread/non-threaded.
I'll see if I can get something for BCB6 together, but I think it will take a while as fairly swamped at work at the moment.
What would be better is a way to auto-generate IDE projects from the jam files. That way you don't need to specify VC6, VC7, VC71, VC8, BCB5, BCB6, CodeWarrior, Eclipse, insert-your-favorite-IDE-here project files for all the examples, libraries, etc.
It's always been my intention that we do something like that, but of course... we need someone to do it! Care to volunteer? The C++ world will thank you!
Ideally, there should be a single program that could process jam files (an extension of bjam?) that can accept a template file that tells it how the project file(s) should be structured.
Yeah, it would have to be part of Boost.Build. I don't even think of it as an extension. Terminology nit: Talking about making it an extension of bjam is a bit weird. bjam is an interpreter with a few built-in primitives for making build systems. Boost.Build (along with your Jamfiles) is a program, essentially, that implements a build system.
This would then allow something like:
genide libs/program_options/examples msvc-7.1
bjam msvc-7.1 project-file
which would generate the project files for the specified project.
Alternatively, there could be plugins written to hook into the various IDEs that will import a bjam project in a friendly GUI way. (This might call the command-line utility so people who prefer command-line or GUI can take their pick.)
Unless it is actually executing bjam to build the project, it is unlikely to work right. There's too much possible variability in Jamfiles, since they are essentially program fragments.
Perhapse what is also needed is a friendly GUI that allows you to configure bjam/BBv2 and create new projects. This infrastructure could hook into your favorite IDE (Eclipse, VS, BCB) so you could edit build and run the jam files from inside the IDE without touching the command line. This would go a long way to increasing the appeal of Boost to a RAD/GUI developer. It should also be possible to edit the project (jam) files directly and have control over their formatting.
You will also need that capability because your GUI won't be able to capture all the possible variability in Jamfiles otherwise.
Summing up, there would be a GUI-based: * setup/configuration of Boost; * project creation wizards to create BBv2 projects; * conversion tool to convert to your favorite IDE format; * hook-ins to allow BBv2 projects to be managed in your favorite IDE.
Not bad. Care to take up the challenge? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Reece Dunn" <msclrhd@hotmail.com> writes:
What would be better is a way to auto-generate IDE projects from the jam files. That way you don't need to specify VC6, VC7, VC71, VC8, BCB5, BCB6, CodeWarrior, Eclipse, insert-your-favorite-IDE-here project files for all the examples, libraries, etc.
It's always been my intention that we do something like that, but of course... we need someone to do it! Care to volunteer? The C++ world will thank you!
I'll take a look at it. I am not promising anything though.
Ideally, there should be a single program that could process jam files (an extension of bjam?) that can accept a template file that tells it how the project file(s) should be structured.
Yeah, it would have to be part of Boost.Build. I don't even think of it as an extension. Terminology nit: Talking about making it an extension of bjam is a bit weird. bjam is an interpreter with a few built-in primitives for making build systems. Boost.Build (along with your Jamfiles) is a program, essentially, that implements a build system.
What I meant was that it would have to sit on top of the bjam/Boost.Build architecture. The Boost.Build (v1 and v2) model does not allow for the collection of information needed to generate the appropriate project file: Taking VC7-8 as an example, there are "solutions" (a text file) that contains the list of projects in it and any dependencies. Each project is associated with a GUID (a unique hexadecimal string created via a Windows/COM API call) - therefore there needs to be GUID generation (and formatting) support in bjam. Each project is an XML file consisting of configuration information and the files (grouped by category - e.g. header, source and resource files) associated with the project. Each source file is built and then linked into the final project. Configurations (usually Debug and Release) describe the setup for building the various files, i.e. what arguments (include path, defines, etc.) to the command line tools (compiler, resource compiler, linker). The problems with using Boost.Build are that: [1] one configuration (variant) is processed, so your would end up with release versions of the project files. Granted, these could be collated after the generation, but this would become: bjam project=myproject release msvc-7.1 bjam project=myproject debug msvc-7.1 collate-project msvc-7.1 [2] the compile and link actions may be done out-of-order, so you would need to keep the targets/options in memory while they are being processed; [3] settings (include paths, etc.) need to be extracted from the compiler and linker and then placed in the global configuration settings; [4] you need to generate a top-level solution file ('myproject') and one project per exe/lib target, possibly specifying post-build actions for install/stage commands. Summing up: it isn't easy being green ;)
which would generate the project files for the specified project.
Alternatively, there could be plugins written to hook into the various IDEs that will import a bjam project in a friendly GUI way. (This might call the command-line utility so people who prefer command-line or GUI can take their pick.)
Unless it is actually executing bjam to build the project, it is unlikely to work right. There's too much possible variability in Jamfiles, since they are essentially program fragments.
The way I indended was to do something like: bjam -n release ... > release.log bjam -n debug ... > debug.log bjam -n profile ... > profile.log # optional? filtering/processing the results so that the .log files would contain the project meta-data in a form that could be easily processed and collated by the project generation tool based on the project template provided.
Perhapse what is also needed is a friendly GUI that allows you to configure bjam/BBv2 and create new projects. This infrastructure could hook into your favorite IDE (Eclipse, VS, BCB) so you could edit build and run the jam files from inside the IDE without touching the command line. This would go a long way to increasing the appeal of Boost to a RAD/GUI developer. It should also be possible to edit the project (jam) files directly and have control over their formatting.
You will also need that capability because your GUI won't be able to capture all the possible variability in Jamfiles otherwise.
A GUI application (either a standalone "build-me" app like John Torjo's Win32GUI app) or an IDE plug-in would end up calling Boost.Build/bjam. That was always a given.
Summing up, there would be a GUI-based: * setup/configuration of Boost; * project creation wizards to create BBv2 projects; * conversion tool to convert to your favorite IDE format; * hook-ins to allow BBv2 projects to be managed in your favorite IDE.
Not bad. Care to take up the challenge?
Sure, why not :) I have a bjam log to xml converter with a really neat XSLT that can take care of various compilers output formats (microsoft, borland, gcc and metroworks at the moment). I am getting it ready to add to the sandbox vault. Reece Haston Dunn Software Engineer, Sophos Web: www.sophos.com Sophos - protecting businesses against viruses and spam
"Reece Dunn" <msclrhd@hotmail.com> writes:
David Abrahams wrote:
"Reece Dunn" <msclrhd@hotmail.com> writes:
What would be better is a way to auto-generate IDE projects from the jam files. That way you don't need to specify VC6, VC7, VC71, VC8, BCB5, BCB6, CodeWarrior, Eclipse, insert-your-favorite-IDE-here project files for all the examples, libraries, etc.
It's always been my intention that we do something like that, but of course... we need someone to do it! Care to volunteer? The C++ world will thank you!
I'll take a look at it. I am not promising anything though.
Ideally, there should be a single program that could process jam files (an extension of bjam?) that can accept a template file that tells it how the project file(s) should be structured.
Yeah, it would have to be part of Boost.Build. I don't even think of it as an extension. Terminology nit: Talking about making it an extension of bjam is a bit weird. bjam is an interpreter with a few built-in primitives for making build systems. Boost.Build (along with your Jamfiles) is a program, essentially, that implements a build system.
What I meant was that it would have to sit on top of the bjam/Boost.Build architecture. The Boost.Build (v1 and v2) model does not allow for the collection of information needed to generate the appropriate project file:
Certainly it does. Especially v2.
Taking VC7-8 as an example, there are "solutions" (a text file) that contains the list of projects in it and any dependencies. Each project is associated with a GUID (a unique hexadecimal string created via a Windows/COM API call) - therefore there needs to be GUID generation (and formatting) support in bjam.
No, we can just build a GUID generation tool and invoke it as part of the process of building the project files.
Each project is an XML file consisting of configuration information and the files (grouped by category - e.g. header, source and resource files) associated with the project. Each source file is built and then linked into the final project. Configurations (usually Debug and Release) describe the setup for building the various files, i.e. what arguments (include path, defines, etc.) to the command line tools (compiler, resource compiler, linker).
The problems with using Boost.Build are that:
[1] one configuration (variant) is processed, so your would end up with release versions of the project files.
No, an arbitrary number of variants are processed.
Granted, these could be collated after the generation, but this would become:
bjam project=myproject release msvc-7.1 bjam project=myproject debug msvc-7.1 collate-project msvc-7.1
I guess not.
[2] the compile and link actions may be done out-of-order,
What do you mean by "out-of-order?" A link action is never done before a compile action that it depends on.
so you would need to keep the targets/options in memory while they are being processed;
targets and options already are kept in memory while they're being processed.
[3] settings (include paths, etc.) need to be extracted from the compiler and linker and then placed in the global configuration settings;
?? Please explain. What do you mean by "extracted from the compiler and linker?" Surely you don't have to specify in the project file any options that are built into the command-line tools and don't need to be specified from the command line?
[4] you need to generate a top-level solution file ('myproject') and one project per exe/lib target, possibly specifying post-build actions for install/stage commands.
I don't see the problem here.
Unless it is actually executing bjam to build the project, it is unlikely to work right. There's too much possible variability in Jamfiles, since they are essentially program fragments.
The way I indended was to do something like:
bjam -n release ... > release.log bjam -n debug ... > debug.log bjam -n profile ... > profile.log # optional?
filtering/processing the results so that the .log files would contain the project meta-data in a form that could be easily processed and collated by the project generation tool based on the project template provided.
Don't do it. Regression testing is already extremely fragile because we're using that approach. We've been intending to generate the XML directly using Boost.Build, but haven't gotten to it yet.
Summing up, there would be a GUI-based: * setup/configuration of Boost; * project creation wizards to create BBv2 projects; * conversion tool to convert to your favorite IDE format; * hook-ins to allow BBv2 projects to be managed in your favorite IDE.
Not bad. Care to take up the challenge?
Sure, why not :)
I have a bjam log to xml converter with a really neat XSLT that can take care of various compilers output formats (microsoft, borland, gcc and metroworks at the moment). I am getting it ready to add to the sandbox vault.
If we get further tied into the log processing approach I think it will be a shame. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Reece Dunn" <msclrhd@hotmail.com> writes:
David Abrahams wrote:
"Reece Dunn" <msclrhd@hotmail.com> writes:
What would be better is a way to auto-generate IDE projects from the jam files. That way you don't need to specify VC6, VC7, VC71, VC8, BCB5, BCB6, CodeWarrior, Eclipse, insert-your-favorite-IDE-here project files for all the examples, libraries, etc.
It's always been my intention that we do something like that, but of course... we need someone to do it! Care to volunteer? The C++ world will thank you!
therefore there needs to be GUID generation (and formatting) support in bjam.
No, we can just build a GUID generation tool and invoke it as part of the process of building the project files.
That is true.
If we get further tied into the log processing approach I think it will be a shame.
What is really needed is a project-generation toolset so you could do something like: bjam release debug msvc-project-7.1 bjam release eclipse-3.0 # release only project files And you end up with the requested project/solution files. I will have a go at writing such a toolset. Reece Haston Dunn Software Engineer, Sophos Web: www.sophos.com Sophos - protecting businesses against viruses and spam
Reece Dunn wrote:
David Abrahams wrote:
What is really needed is a project-generation toolset so you could do something like:
bjam release debug msvc-project-7.1 bjam release eclipse-3.0 # release only project files
And you end up with the requested project/solution files. I will have a go at writing such a toolset.
Is it really needed? Earlier in the street Reece proposed two *alternative* solutions: * conversion tool to convert to your favorite IDE format; * hook-ins to allow BBv2 projects to be managed in your favorite IDE. I think the second alternative is better. For example these hook-ins (Boost.Build project type in case of MSVC7+) will make implementation of "project creation wizards to create BBv2 projects" possible. For what do we need these IDE projects? I think the only purpose is to make it easier to work on Boost libraries. It's much easier for those who are used to IDE to press F7 than "up + enter" or "up + up + enter" in case of CLI. Also you don't have to leave text editor to run, can easily invoke debugger etc. But to make all these things possible in MSVC we don't need neither to hook-up in IDE, nor to generate rather complex .vcproj files. Besides .vcproj complexity, having the same information duplicated in both Jamfile and vcproj is a bad thing because synchronizing them will be a pain which boost developers don't deserve. We can generate MSVC "make" projects instead, which are much simpler than both full-flebecause they only need a couple of lines to invoke bjam.exe. MSVC will even parse bjam output to show compilation errors in Tasks window. What do you think? Andrey P.S. Can anyone look at BCB/CW extension capabilities and find the easiest way to get them supporting Boost.Build projects?
On 5/27/05, Andrey Melnikov <melnikov@simplexsoft.com> wrote:
Reece Dunn wrote:
David Abrahams wrote:
What is really needed is a project-generation toolset so you could do something like:
bjam release debug msvc-project-7.1 bjam release eclipse-3.0 # release only project files
And you end up with the requested project/solution files. I will have a go at writing such a toolset.
Is it really needed? Earlier in the street Reece proposed two *alternative* solutions:
* conversion tool to convert to your favorite IDE format; * hook-ins to allow BBv2 projects to be managed in your favorite IDE.
P.S. Can anyone look at BCB/CW extension capabilities and find the easiest way to get them supporting Boost.Build projects?
Why not generate CMake (http://cmake.org) input from bjam? It seems to work well from my limited experience on VC projects and Makefiles. Support exists for Borland and various Visual Studio flavors. XCode and CodeWarrior seem to in the works. Other pros: It's open source, and support from developers on the list has been excellent in my experience. -shishir -- The man who doesn't read good books has no advantage over the man who can't read them. - Mark Twain
Andrey Melnikov <melnikov@simplexsoft.com> wrote:
[...] * hook-ins to allow BBv2 projects to be managed in your favorite IDE.
I think the second alternative is better. For example these hook-ins (Boost.Build project type in case of MSVC7+) will make implementation of "project creation wizards to create BBv2 projects" possible. [...] What do you think?
This would replace the need to invoke a command line executable alien to the targeted user base by the need to download, install, and use a plugin alien to them. Really, if you want to boost the interest in boost, make using it easy on all platforms. This means it should be doable in a way that's very common on that platform. For Unix, invoking CLI tools is common, so downloading and invoking a special tool might be OK. On Windows, downloading a project file is common, so ideally project files is what boost should provide. For obvious reasons, those should somehow be generated from whatever Boost.Build uses. Whether this is possible I don't know. But that's the ideal.
Andrey [...]
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
"Reece Dunn" wrote:
What is really needed is a project-generation toolset so you could do something like:
bjam release debug msvc-project-7.1 bjam release eclipse-3.0 # release only project files
And you end up with the requested project/solution files. I will have a go at writing such a toolset.
There are such tools out there, my employer have some internal tools doing similat things. TrollTech has a tool called QMake. You can however also find excelent "properly lisenced" tools for Boost. Check out the Make Project Creator (MPC) tool used in ACE/TAO ($ACE_ROOT/MPC/...). This tool is a set of perl scripts which in my mind does an excelent job against MSVC and GnuMake which I have tested. According to the documentation it supports many other build tools. Its imput is basically a simple declaration file like: // -*- MPC -*- // Advanced_ch_3.mpc,v 1.4 2004/06/20 19:50:31 ossama Exp project(*client) : taoexe, portableserver { requires += exceptions corba_messaging source_files { client.cpp } } project(*server) : taoexe, portableserver { requires += exceptions source_files { server.cpp } } These files has to be generated by Boost.Build (bjam), then MPC or similar can be invoked to create the target build/project/solution environment. MPC uses the input file like the one above, in addition to this there are a lot of rules that are applied based on task, target, etc. which is part of the tool or customilization of it. See attached USAGE file for some more info. If added dependency on perl is a problem, then at a minimum I suggest using MPC as a way to get a head start of what needs to be added to bjam. It would make bjam a lot more interesting :o) By the way, in my opinion - the most interesting usage of such a tool is not to build Boost, but to get users up and running on using and modifying example code. Good Luck... Bjørn
On 5/25/05, Paul A Bristow <pbristow@hetp.u-net.com> wrote:
Recently we had a flurry of discussion of why Boost is not more widely used.
I have used some bits of Boost happily for years, but recently I felt I had to use it 'properly' so concluded it was time I used the bjam build system - something I had felt looked a bit clever.
Indeed my suspicion was proved correct - I couldn't get it to work. The instructions are far too Unix/Make oriented for this mere Windows hacker; the Wiki Windows specific instructions are much better but suggest copying (duplicating) a lot of files to avoid an addition to the include directories, and don't apply to the most recent compilers.
Victor Wagner gave some hints recently using environment variables, but not the full text.
I don't doubt the usefulness of the bjam to the congescenti - only with this could the incredibly impressive build & test system allow all the cracks and chasms of compiler non-compliance and language imprecision to be papered over - Boost's great strength.
But if we are to interest your average Windows IDE programmer, for whom MAKE is a blank or a distant nightmare, IMO we need some much better and simpler instructions, including lots of examples of input and output, and to be as well tested as the rest of Boost code. Like it or not, these are the potential customers and I spoken to many who are put off by the 'build barrier'.
I suggest that we explicitly say that you can use all of Boost (except the ones that must have built libraries) by adding to the include list - and say exactly how in Windows IDE-ese.
If you share my concern, would some someone like to prepare something? Or at least provide details of their way of doing it. I will be willing to help with checking/editing.
Paul
Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com
Paul - I use VS2003 and VS6 (for legacy projects). This is the process I tend to follow when setting up a new machine (I've done several of them, both for myself and other people recently, so I'm reasonably well practised!): 1. Download and unpack Boost! 2. Open up a Visual Studio 2003 command prompt window (this is on the Start Menu entry for Visual Studio 2003, and has pre-run vcvars32.bat) and 'cd' to the root Boost directory. Execute the command bjam -sTOOLS=vc-7_1 --prefix=c:\lib\boost I don't have Python installed, so I just ignore the Boost.Python error message when it can't find a Python installation. 3. Open up a second command prompt window and run the vcvars32.bat for Visual Studio 6. Then execute this command bjam -sTOOLS=msvc --prefix=c:\lib\boost When I use Visual Studio, I use environment variables to point at the libraries I use (not just Boost - libxml, libxslt, wtl as well) and insert these environment variables into the 'Additional Include Directories' and 'Additional Library Path' options in the VS project settings dialogs. For example, I might define these environment variables: BOOST_INC_ROOT=C:\lib\boost\include\boost-1_32 BOOST_LIB_ROOT=C:\lib\boost\lib and insert '$(BOOST_INC_ROOT)' into the 'Additional Include Directories' setting and '$(BOOST_LIB_ROOT)' into the 'Additional Library Path' setting. One extra detail that I find eases things is that I use Joshua Jensens Solution Build Environment add-in (http://www.workspacewhiz.com/OtherAddins.html#SolutionBuildEnvironment) to define these environment variables (for VS2003 - I wrote an equivalent add-in for VS6). This means I can vary the environment variable settings on a project-by-project basis, as the environment is defined by a file thats part of hte project. This helps for legacy projects (I've got up to 5 versions of Boost available, depending on the machine I'm at) and also where the install location varies. One final point - whoever came up with the autolinking scheme (think it was John Maddock?) - thank you very much - that makes life *so* much easier! HTH Stuart Dootson
On 5/25/05, Stuart Dootson <stuart.dootson@gmail.com> wrote:
1. Download and unpack Boost!
2. Open up a Visual Studio 2003 command prompt window (this is on the Start Menu entry for Visual Studio 2003, and has pre-run vcvars32.bat) and 'cd' to the root Boost directory. Execute the command
bjam -sTOOLS=vc-7_1 --prefix=c:\lib\boost
But to do this you need to build (and install someplace in your PATH) or download bjam first. Its not hard, but this may not be imediately obvious to the newbie. I really think the Getting Started guide is more than adequate, and is concise and easy to follow. There are gigantic yellow numbers next to the important steps. Perhaps an "ultra-quick-start for the command line averse" could be added, but really how much more hand-holding does one need? -- Caleb Epstein caleb dot epstein at gmail dot com
On 5/25/05, Caleb Epstein <caleb.epstein@gmail.com> wrote:
On 5/25/05, Stuart Dootson <stuart.dootson@gmail.com> wrote:
1. Download and unpack Boost!
2. Open up a Visual Studio 2003 command prompt window (this is on the Start Menu entry for Visual Studio 2003, and has pre-run vcvars32.bat) and 'cd' to the root Boost directory. Execute the command
bjam -sTOOLS=vc-7_1 --prefix=c:\lib\boost
But to do this you need to build (and install someplace in your PATH) or download bjam first. Its not hard, but this may not be imediately obvious to the newbie.
I really think the Getting Started guide is more than adequate, and is concise and easy to follow. There are gigantic yellow numbers next to the important steps. Perhaps an "ultra-quick-start for the command line averse" could be added, but really how much more hand-holding does one need?
You're right, I forgot a step - I was going to download the Boost distro to see if bjam.exe was in it, but the Sourceforge downloads area is blocked at work, so I couldn't. I would tend to agree with you that (for me) the Getting Started guide is sufficient - but then, I've always been comfortable with using the command-line (I've got a VAX/VMS and Unix history before Windows). There are a lot of Windows developers out there who haven't got that level of comfort. Stuart Dootson
On 25 May 2005, at 13:37, Stuart Dootson wrote:
On 5/25/05, Caleb Epstein <caleb.epstein@gmail.com> wrote:
On 5/25/05, Stuart Dootson <stuart.dootson@gmail.com> wrote:
1. Download and unpack Boost!
2. Open up a Visual Studio 2003 command prompt window (this is on the Start Menu entry for Visual Studio 2003, and has pre-run vcvars32.bat) and 'cd' to the root Boost directory. Execute the command
bjam -sTOOLS=vc-7_1 --prefix=c:\lib\boost
But to do this you need to build (and install someplace in your PATH) or download bjam first. Its not hard, but this may not be imediately obvious to the newbie.
I really think the Getting Started guide is more than adequate, and is concise and easy to follow. There are gigantic yellow numbers next to the important steps. Perhaps an "ultra-quick-start for the command line averse" could be added, but really how much more hand-holding does one need?
You're right, I forgot a step - I was going to download the Boost distro to see if bjam.exe was in it, but the Sourceforge downloads area is blocked at work, so I couldn't.
I would tend to agree with you that (for me) the Getting Started guide is sufficient - but then, I've always been comfortable with using the command-line (I've got a VAX/VMS and Unix history before Windows). There are a lot of Windows developers out there who haven't got that level of comfort.
Stuart Dootson
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Ditto, I find that the Getting started guide was easy as pie to use for setting up with Windows and VS.NET. Again though, I also am quite conformable with the command line and using bits of Linux here (at the same time I'm not unix pro). TBH, I think any self respecting C++ user should have experience in a cross platform environment. I'm surprised how many Windows-only programmers there are out there. Jase
Jason Earl <Jason@hybd.net> wrote:
[...] TBH, I think any self respecting C++ user should have experience in a cross platform environment. I'm surprised how many Windows-only programmers there are out there.
Do you want widespread use of boost or do you want widespread use of boost among programmers who know their way around with a shell?
Jase
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
On 25 May 2005, at 14:00, Hendrik Schober wrote:
Jason Earl <Jason@hybd.net> wrote:
[...] TBH, I think any self respecting C++ user should have experience in a cross platform environment. I'm surprised how many Windows-only programmers there are out there.
Do you want widespread use of boost or do you want widespread use of boost among programmers who know their way around with a shell?
Well, yes that is a valid point. Being a web designer / programmer as my main job, I do realise the importance of making something that user / client orientated. Obviously, we work hard to make sure that a project is useable by the largest possible audience. However in the case of Boost, it's target audience is not your average client / dumb computer user. It's aimed at professional C++ programmer. If a C/C++ programmer is expected to understand things like memory management / allocation concepts and policies, then they shouldn't have any problem with using a shell. After all anyone with experience with Unix will realise how of an advantage a shell is in terms of flexibility when it comes to deploying stuff with scripts etc. At the same time I'm certainly not against any ideas to simplify the install process on certain platforms, after all it makes our life as programmers easier (Just look at the Mac platform now, it appeals to professional developers, while remaining dummy friendly enough for you nan to use). I'm just saying that most C++ programmers really shouldn't have issues with being able to use a shell, after all it's a lot easier to understand than most things programmers do with C++, likewise a C++ programmer should comfortable with setting up their IDE, after all using VS.NET isn't the most taxing of IDE's. I do agree with Reece that UI based systems for configuring Boost would be a nice icing on the cake in the long run.
Jase
Schobi
-- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving" Terry Pratchett
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jason Earl <Jason@hybd.net> wrote:
[...] However in the case of Boost, it's target audience is not your average client / dumb computer user. It's aimed at professional C++ programmer. If a C/C++ programmer is expected to understand things like memory management / allocation concepts and policies, then they shouldn't have any problem with using a shell. After all anyone with experience with Unix will realise how of an advantage a shell is in terms of flexibility when it comes to deploying stuff with scripts etc.
There are millions of C++ users out there who almost never have the need to use a command line tool. Still, many of them are doing very professional work. They see the advantage of their IDE over your arcane command line and you'd be just amazed to see how they do their work using it as they would be seeing you typing. C++ programmers are expected to learn a lot more than memory etc. They need to learn the language extensions/tweaks necessary for their job, 3rd-party APIs, other libs they need to use, build systems, in-house style guides, new languages how to circumvent bugs in their tools... To many, using command line tools is just one of many things they'd love to learn to do better one day -- and never find the time to actually do so. When you're rushing from deadline to deadline you're just looking at the stuff you need for your next project and sigh because it's just a tenth of what you'd like to look at. On Windows, using command line tools isn't within this tenth for many professionals. And for those, installing boost is a hassle. You might say you'Re fine with that and this is OK with me. Just don't diss programmers that don't use command line tools in their daily work. And don't suppose boost is easy to setup if for those. It's not.
[...]
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
I guess everyone has their preference. Though I'm a Windows user at heart, I do find that many of the WYSIWYG tools to me have a much higher learning curve than doing stuff the old fashioned command line at times. Certainly, as web design/programmer, I detest IDE's, and find nothing beats jEdit for everything that doesn't depend on Photoshop. Maybe I'm a control freak. At the same time, getting things working in Windows is so much easier than Linux, things do work out of the box, and that's where I'm thankful for a UI. I guess this argument is very much down to personal taste. Again, as I said, much as I have said that I personally don't have a problem with CLI build systems, I do agree with Reece that a GUI system would be a nice icing on the cake. However I would not want want to see good old fashioned CLI build system be replaced outright (and I can't see that happening anyway). I still think that the CLI based build system is fine, it just might need some adjusting so that it's simpler to use as users don't have to see kilobytes of make commands being issues. Jason On 25 May 2005, at 14:58, Hendrik Schober wrote:
Jason Earl <Jason@hybd.net> wrote:
[...] However in the case of Boost, it's target audience is not your average client / dumb computer user. It's aimed at professional C++ programmer. If a C/C++ programmer is expected to understand things like memory management / allocation concepts and policies, then they shouldn't have any problem with using a shell. After all anyone with experience with Unix will realise how of an advantage a shell is in terms of flexibility when it comes to deploying stuff with scripts etc.
There are millions of C++ users out there who almost never have the need to use a command line tool. Still, many of them are doing very professional work. They see the advantage of their IDE over your arcane command line and you'd be just amazed to see how they do their work using it as they would be seeing you typing. C++ programmers are expected to learn a lot more than memory etc. They need to learn the language extensions/tweaks necessary for their job, 3rd-party APIs, other libs they need to use, build systems, in-house style guides, new languages how to circumvent bugs in their tools... To many, using command line tools is just one of many things they'd love to learn to do better one day -- and never find the time to actually do so. When you're rushing from deadline to deadline you're just looking at the stuff you need for your next project and sigh because it's just a tenth of what you'd like to look at. On Windows, using command line tools isn't within this tenth for many professionals. And for those, installing boost is a hassle. You might say you'Re fine with that and this is OK with me. Just don't diss programmers that don't use command line tools in their daily work. And don't suppose boost is easy to setup if for those. It's not.
[...]
Schobi
-- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving" Terry Pratchett
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jason Earl wrote:
I guess everyone has their preference. Though I'm a Windows user at heart, I do find that many of the WYSIWYG tools to me have a much higher learning curve than doing stuff the old fashioned command line at times. Certainly, as web design/programmer, I detest IDE's, and find nothing beats jEdit for everything that doesn't depend on Photoshop. Maybe I'm a control freak.
IDEs can be very powerful. For example, I mainly use the VS IDE as an "enhanced text editor". Features like syntax highlighting, virtual whitespace, visible whitespace and regular expression search/replace simplify program development. Also, the VS IDE has very powerful debug tools that allow you to step through a program, examining argument values and the call stack. That said, I use bash and bjam/BBv2 to build my projects, processing the resultant data to an XML file to display nice summaries and see more specifically where a problem occured, if any. I am not too keen on the project creation tools as they have a habit of adding things you don't want, use a specific formatting that you may not like and require you to change the project settings if you want to output the binary files to a different directory for example. I have also been tripped up by modifying some setting in the current configuration and not "all configurations". A good GUI should make it simple for the user to do common tasks and even setting up complex ones. It should also give the user control if they need/request it.
At the same time, getting things working in Windows is so much easier than Linux, things do work out of the box, and that's where I'm thankful for a UI.
I am a huge fan of the keyboard shortcuts in Windows. I am also a fan of bash :).
I guess this argument is very much down to personal taste. Again, as I said, much as I have said that I personally don't have a problem with CLI build systems, I do agree with Reece that a GUI system would be a nice icing on the cake. However I would not want want to see good old fashioned CLI build system be replaced outright (and I can't see that happening anyway).
I was not intending the GUI layer to replace the CLI. My idea was simple: give the user the *choice*. If you are a novice, you can use the GUI to simplify the setup and configure things for you. This would probably mean providing a pre-build program that will configure the environment, build bjam, build Boost for the compiler(s) you select and integrate it with your favorite IDE(s). Experienced users/CLI gurus can choose to configure Boost manually. It would be nice to have a set of common problems encountered by users and their solutions.
I still think that the CLI based build system is fine, it just might need some adjusting so that it's simpler to use as users don't have to see kilobytes of make commands being issues.
I have a bjam output logger that generates XML output (based on the regression test version) to a file. You still see the bjam output (using --echo), but you also get a nice XML file that uses an XSLT file to view it as HTML, similar to how the VS IDE works. I will make this available in the sandbox vault. Reece Haston Dunn Software Engineer, Sophos Web: www.sophos.com Sophos - protecting businesses against viruses and spam
"Jason Earl" <Jason@hybd.net> wrote in message news:a92cb275d8bab18d3c31671b1a52f8cd@hybd.net...
On 25 May 2005, at 14:00, Hendrik Schober wrote:
Jason Earl <Jason@hybd.net> wrote:
[...] TBH, I think any self respecting C++ user should have experience in a cross platform environment. I'm surprised how many Windows-only programmers there are out there.
...
However in the case of Boost, it's target audience is not your average client / dumb computer user. It's aimed at professional C++ programmer. If a C/C++ programmer is expected to understand things like memory management / allocation concepts and policies, then they shouldn't have any problem with using a shell. After all anyone with experience with Unix will realise how of an advantage a shell is in terms of flexibility when it comes to deploying stuff with scripts etc.
As an evidently non-"self respecting C++ user", I understand "things like memory management / allocation concepts and policies", while I find it a pain to have to remember arcane commands to do things that I can do with a click or a drag & drop. I cheerfully admit to keeping my Unix experience to a minimum. I have enough to do to keep up with the complexities of C++ and boost functionality, without learning the intricacies of yet another script language. As a matter of fact, one of the things I love about boost is how one can implement in C++ what used to require a .bat file to accomplish. The point of all of this is that a "self respecting C++ user" should realize that not all users of the products of our labors share the same usage patterns as our selves. Jeff Flinn
Caleb Epstein <caleb.epstein@gmail.com> wrote:
[...] I really think the Getting Started guide is more than adequate, and is concise and easy to follow. There are gigantic yellow numbers next to the important steps. [...] really how much more hand-holding does one need?
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 After quite a pause ("what's it doing now?") it spit out a lengthy messagethat that I have an incorrect configuration. It couldn't find Python. Mhmm. Do I need this? Will it even work without Python? (I know it will. But not from the guide.) Next thing it emits is don't know how to make bjam Yikes! What does that mean? It surely doesn't mean it wants to compile/link bjam as I am /running/ it already, right? Scary. Right after that, it emitted don't know how to make -sTOOLS=VC71_ROOT Now I am really really baffled. I mean, I pasted that line from the guide (except for replacing "gcc" with what I thought the guide says I need to replace it with). Doesn't that thing even recognise its options? Finally, it advices ...patience... Oh good. So I'll wait. Further: ...found 4471 targets... ...updating 1123 targets... ...can't find 2 targets... Um, what are targets? Why does it only "update" a quarter of them? Why wouldn't it find 2 of them? I read the guide again. Damn! I messed this up! I need to pass "vc", not "VC71_ROOT"! The guid is a bit terse in that area... CTRL-C C:\Temp\Download\boost\boost_1_32_0>..\bjam.exe bjam "-sTOOLS=vc" stage Alas, same result. Excep that now it don't know how to make -sTOOLS=vc Huh? Well, it says I should be patient, so I just let it do whatever it does. There really are a few libs in "bin" at the end. And the thing says ...updated 1120 targets... Mhmm. Three missing. It might have even emitted an error message. No way I'm going to wade through 3-4k lines of messages to find those three. Now I would need to link to this stuff. But where exactly do I need to point my linker at? The guide has something on automatic linking on Windows, but I can't find where in the folder hierarchy this assumes I'm anchored. Still long ways to go before I can start to work. Add to this that, as with all new stuff, I will still stumble more later while using this, that I would have to write a usage guide for my fellows if I want to use this (hey, some of them aren't as good reading English, they will never be able to follow this guide!), and that we need to figure this out for another handful of platforms -- and I start to think if it really is worth all the hassle. Conclusion: I have seen smoother installations on Windows, I have installed easier to build libs, and I have seen guides that weren't written for mere insiders. I'm no command-line afficinado, I can barely read makefiles, and I am used to having a GUI and online-help for every option. Call me dumb, but I am one of millions of potential boost users. We use boost since years ago, when I threw out all home-grown smart pointers and replaced them by boost's. So we /know/ boost is worth quite a lot of hassle and we even use one library that's not headers-only. (However, this one -- regex -- comes with a makefile and this we knew how to integrate into the build.) But if this was my first look at boost, I'd delete it right away. Seriously, on this platform are millions of C++ users that only heard very vague rumours of C++ being standardized -- if they heard about it at all. Those don't see much benefit it smart pointers, consider the MPL to be black art, and can't be bothered if it isn't really easy to use. Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Hendrik Schober | Sent: 25 May 2005 14:46 | To: boost@lists.boost.org | Subject: [boost] Re: Customer Friendlier Boost Installation | | Caleb Epstein <caleb.epstein@gmail.com> wrote: | > [...] | > I really think the Getting Started guide is more than | adequate, and is | > concise and easy to follow. There are gigantic yellow | numbers next to | > the important steps. [...] really how much more hand-holding | > does one need? | | | 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 < Big snip but my 'log' looks a bit like this - but different set of problems, and I was trying to use the current CVS AND MSVC 8.0 beta 2. Should have learn to walk before I tried to run :-(( I need a LOT more hand holding please - though I can dimly remember using command lines decades ago ;-) I say again - the process MUS be OK to be achieving such stunning results, but the documentation is NOT. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com
At 07:30 2005-05-25, Paul A Bristow wrote:
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Hendrik Schober | Sent: 25 May 2005 14:46 | To: boost@lists.boost.org | Subject: [boost] Re: Customer Friendlier Boost Installation | | Caleb Epstein <caleb.epstein@gmail.com> wrote: | > [...] | > I really think the Getting Started guide is more than | adequate, and is | > concise and easy to follow. There are gigantic yellow | numbers next to | > the important steps. [...] really how much more hand-holding | > does one need? | | | 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
< Big snip
but my 'log' looks a bit like this - but different set of problems,
and I was trying to use the current CVS AND MSVC 8.0 beta 2. Should have learn to walk before I tried to run :-((
I build boost 4 times a day (CVS), vc++7.1 and vc++8.0 (then run the regression tests) the script I use is published where the regression results are (just click on RudbekAssociates) I grant you that I'm using regression.py to do lots of the work, but I'm using it in pieces so what it's doing should be pretty obvious, if it's not, you know where to find me, my email address is in the same place.
I need a LOT more hand holding please - though I can dimly remember using command lines decades ago ;-)
I say again - the process MUS be OK to be achieving such stunning results, but the documentation is NOT.
Paul
Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
You've probably come out with a worst case scenario with regards to that attempt to compile things, and I do remember a few things being a pain initially when compiling for the first time. However, it didn't take long for me to make intelligent guesses on what to do to get things working, and it was only minutes before I managed to get things working smoothly when I last tried. This is certainly a lot less painless than a some of the builds I've done on Linux for web stuff. I think a lot of Windows users are too used to things just working out of the box, and give up if things don't work like that. As for understanding what targets are etc, I think most developers will know what targets are. There is a fine level between displaying too much info and not displaying enough. I get increasingly annoyed by Windows apps that do the complete opposite and don't tell you anything when something goes pear shaped. It becomes even harder to pin point an error then as you have no info to go by. Least when you get errors with building you can copy and paste into google and normally get answers if you don't understand what the reason is behind the error. Despite all the errors people might get with installing, Boost does have this excellent mailing list where people can quickly get the help they need. Maybe it would be good to have some control over build verbosity (there probably already is some, I just haven't looked yet), Maybe logging the build info to a file would be better and then logging errors, messages etc to the screen (and maybe a separate) log file. You really can't complain at long error messages. After all C++ programmers should be used to them, they happen all of the time with template based code. Jason On 25 May 2005, at 14:46, Hendrik Schober wrote:
Caleb Epstein <caleb.epstein@gmail.com> wrote:
[...] I really think the Getting Started guide is more than adequate, and is concise and easy to follow. There are gigantic yellow numbers next to the important steps. [...] really how much more hand-holding does one need?
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 After quite a pause ("what's it doing now?") it spit out a lengthy messagethat that I have an incorrect configuration. It couldn't find Python. Mhmm. Do I need this? Will it even work without Python? (I know it will. But not from the guide.) Next thing it emits is don't know how to make bjam Yikes! What does that mean? It surely doesn't mean it wants to compile/link bjam as I am /running/ it already, right? Scary. Right after that, it emitted don't know how to make -sTOOLS=VC71_ROOT Now I am really really baffled. I mean, I pasted that line from the guide (except for replacing "gcc" with what I thought the guide says I need to replace it with). Doesn't that thing even recognise its options? Finally, it advices ...patience... Oh good. So I'll wait. Further: ...found 4471 targets... ...updating 1123 targets... ...can't find 2 targets... Um, what are targets? Why does it only "update" a quarter of them? Why wouldn't it find 2 of them? I read the guide again. Damn! I messed this up! I need to pass "vc", not "VC71_ROOT"! The guid is a bit terse in that area... CTRL-C C:\Temp\Download\boost\boost_1_32_0>..\bjam.exe bjam "-sTOOLS=vc" stage Alas, same result. Excep that now it don't know how to make -sTOOLS=vc Huh? Well, it says I should be patient, so I just let it do whatever it does. There really are a few libs in "bin" at the end. And the thing says ...updated 1120 targets... Mhmm. Three missing. It might have even emitted an error message. No way I'm going to wade through 3-4k lines of messages to find those three. Now I would need to link to this stuff. But where exactly do I need to point my linker at? The guide has something on automatic linking on Windows, but I can't find where in the folder hierarchy this assumes I'm anchored. Still long ways to go before I can start to work. Add to this that, as with all new stuff, I will still stumble more later while using this, that I would have to write a usage guide for my fellows if I want to use this (hey, some of them aren't as good reading English, they will never be able to follow this guide!), and that we need to figure this out for another handful of platforms -- and I start to think if it really is worth all the hassle.
Conclusion: I have seen smoother installations on Windows, I have installed easier to build libs, and I have seen guides that weren't written for mere insiders. I'm no command-line afficinado, I can barely read makefiles, and I am used to having a GUI and online-help for every option. Call me dumb, but I am one of millions of potential boost users. We use boost since years ago, when I threw out all home-grown smart pointers and replaced them by boost's. So we /know/ boost is worth quite a lot of hassle and we even use one library that's not headers-only. (However, this one -- regex -- comes with a makefile and this we knew how to integrate into the build.) But if this was my first look at boost, I'd delete it right away. Seriously, on this platform are millions of C++ users that only heard very vague rumours of C++ being standardized -- if they heard about it at all. Those don't see much benefit it smart pointers, consider the MPL to be black art, and can't be bothered if it isn't really easy to use.
Schobi
-- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving" Terry Pratchett
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jason Earl <Jason@hybd.net> wrote:
You've probably come out with a worst case scenario
Have I? So what did I do wrong to get me into this? I just downloaded the stuff and followed the guide. It seems easy to hit the worst case.
with regards to that attempt to compile things, and I do remember a few things being a pain initially when compiling for the first time. However, it didn't take long for me to make intelligent guesses on what to do to get things working, and it was only minutes before I managed to get things working smoothly when I last tried. This is certainly a lot less painless than a some of the builds I've done on Linux for web stuff.
I think a lot of Windows users are too used to things just working out of the box, and give up if things don't work like that.
If wanted, I'd most likely find out, too. The original argument was that it takes too much effort to do this. I second that. There's too many out there who simply won't spend that effort (and who don't share your resentiments against anything but shell typing). I repeat: Do you want widespread use of boost or do you want widespread use of boost among programmers who know their way around with a shell?
As for understanding what targets are etc, I think most developers will know what targets are. [...]
With thinking a few seconds I came up with three overloaded meanings we use the term for here. I still don't know what exactly targets are in the boost build system. And frankly, don't think I should need to read its documentation in order to know. There's a lot I have to fit into one day, it's already tight without reading it.
Despite all the errors people might get with installing, Boost does have this excellent mailing list where people can quickly get the help they need.
Do you want all users come to the mailing list and ask? (Then why have a build system at all?)
Maybe it would be good to have some control over build verbosity (there probably already is some, I just haven't looked yet), Maybe logging the build info to a file would be better and then logging errors, messages etc to the screen (and maybe a separate) log file.
Yes, I thought of this myself. But the heck -- there's so many libs out there I will never have the time to look at. If I wouldn't know boost is more than just another one of those, I would just forget about it keep hacking.
You really can't complain at long error messages.
Why not? (Where would we be hadn't we complained all the time? <g> )
After all C++ programmers should be used to them, they happen all of the time with template based code.
True. My compiler smoetimes spits out 3-4k error messages for templates, too. But it gives me the convenience of easily navigating among them. (And I still complain to my vendor that I want this even easier!)
Jason
On 25 May 2005, at 14:46, Hendrik Schober wrote: [...]
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
On Wed, May 25, 2005 at 05:08:49PM +0200, Hendrik Schober wrote:
Jason Earl <Jason@hybd.net> wrote:
You've probably come out with a worst case scenario
Have I? So what did I do wrong to get me into this? I just downloaded the stuff and followed the guide. It seems easy to hit the worst case.
Typing the wrong thing almost every time you had to type something! That's not a defence of the build system though. Instead of all this quibbling about who prefers CLI and who prefers GUI, the people who are bothered about it should help Paul come up with a simplified guide and/or submit patches to improve the docs.
Despite all the errors people might get with installing, Boost does have this excellent mailing list where people can quickly get the help they need.
Actually, I think questions about building boost should go to the users list, not here. jon -- Progress is not made by early risers. Progress is made by lazy men looking for easier ways to do things.
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
On Wed, May 25, 2005 at 05:08:49PM +0200, Hendrik Schober wrote:
Jason Earl <Jason@hybd.net> wrote:
You've probably come out with a worst case scenario
Have I? So what did I do wrong to get me into this? I just downloaded the stuff and followed the guide. It seems easy to hit the worst case.
Typing the wrong thing almost every time you had to type something! That's not a defence of the build system though.
Instead of all this quibbling about who prefers CLI and who prefers GUI, the people who are bothered about it should help Paul come up with a simplified guide and/or submit patches to improve the docs.
Despite all the errors people might get with installing, Boost does have this excellent mailing list where people can quickly get the help they need.
Actually, I think questions about building boost should go to the users list, not here.
Or to the jamboost list, if you think your questions may lead to discussion about how to change the design of the build system. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Jonathan Wakely <cow@compsoc.man.ac.uk> wrote:
[...]
Have I? So what did I do wrong to get me into this? I just downloaded the stuff and followed the guide. It seems easy to hit the worst case.
Typing the wrong thing almost every time you had to type something!
Yes, I know, I didn't do very good in this test. Yet -- I don't think anyone working on Win/Mac here at my job would do better. People aren't used to having to type their commands. They make silly errors like I did.
That's not a defence of the build system though.
Instead of all this quibbling about who prefers CLI and who prefers GUI, the people who are bothered about it should help Paul come up with a simplified guide and/or submit patches to improve the docs.
I'd be willing to help with the docs. That's why I posted.
[...] jon
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
I've been following this thread for a bit. I think that the boost community would do well to do the following: - precompile boost for Windows compilers - package up the headers and .libs in a MSI installation script (or some other native windows installer) - provide that for download That way we sidestep the whole issue of using JAM. This has two benefits: - Windows programmers expect to be able to click on a link and simply download the answer. - Windows programmers would get a reliable library that was built under controlled circumstances. We'd all spend less time supporting folks who have trouble driving the compiler via JAM, and/or who have somehow produced a corrupt boost library. In fact, we could even add a "create an installer script" target to the JAM process in order to facilitate making and publishing the installation script for us. Personally, I did use JAM successfully, but I also encountered a number of error messages that I quickly worked through, and didn't think much about. It would have been a barrier to someone less experienced though, and we don't want that. Rob.
Robert Mathews wrote:
I've been following this thread for a bit.
I think that the boost community would do well to do the following: - precompile boost for Windows compilers - package up the headers and .libs in a MSI installation script (or some other native windows installer) - provide that for download
The problem is that each compiler adds several hundred megabites to the install, so supporting VC6 (which patched version?), VC7, VC71, VC8 (which beta/CTP?), BCB5, BCB6, CodeWarrior 8.x/9.x, gcc (which version??) you will end up with an install that is on several DVDs!!! The easiest way would be to have the installer auto-detect compilers on your machine and allow the user to edit the list, adding/modifying compilers as they need, then select which ones they want to build the libraries for. It should be possible to build again at a later stage when you add a new compiler, etc. Granted, this could make the install take a long time (if you are supporting many different compilers), but the user should be able to (optionally) see the output and provide a way of estimating how long the build phase will take (so the user knows that they can come back in an hour or whatever). An installer like ths could be intelligent enough to extract and/or build only the ilbraries you want, for example, you could just build the Filesystem library.
That way we sidestep the whole issue of using JAM. This has two benefits: - Windows programmers expect to be able to click on a link and simply download the answer. - Windows programmers would get a reliable library that was built under controlled circumstances. We'd all spend less time supporting folks who have trouble driving the compiler via JAM, and/or who have somehow produced a corrupt boost library.
What if you install a library for VC6.5 and you only have VC6.0? Building a project could then break when you link against the 6.5 versions.
Personally, I did use JAM successfully, but I also encountered a number of error messages that I quickly worked through, and didn't think much about. It would have been a barrier to someone less experienced though, and we don't want that.
The install/build GUI could process this so that it generates a friendlier summary informing you of what broke. Reece Haston Dunn Software Engineer, Sophos Web: www.sophos.com Sophos - protecting businesses against viruses and spam
"Reece Dunn" <msclrhd@hotmail.com> wrote in message news:BAY101-F51E45E48EC4EA585C0E9EA00E0@phx.gbl...
Robert Mathews wrote:
I've been following this thread for a bit.
I think that the boost community would do well to do the following: - precompile boost for Windows compilers - package up the headers and .libs in a MSI installation script (or some other native windows installer) - provide that for download
The problem is that each compiler adds several hundred megabites to the install, so supporting VC6 (which patched version?), VC7, VC71, VC8 (which beta/CTP?), BCB5, BCB6, CodeWarrior 8.x/9.x, gcc (which version??) you will end up with an install that is on several DVDs!!!
On my machine, the compiled libraries + source (no object files) takes 700MB for all the models for VC71. But, that's uncompressed. Compressed is a different story. When I compress my directory, I get a 90% reduction in size - more like 70MB. But that's still too large. However, a single compile model - ie, single threaded (debug+release) - takes only 4.6MB, which is easily downloadable. And all programming shops I've been to pick a particular compiler, programming model, and then stick with it, so the following idea should work: So, what you'd do it is write a installer stub that 1) queried for compiler model 2) queried for compile model (single threaded, multithreaded, static, dll etc) And then took that information and went off and downloaded the correct library. Seems simply enough to me. Much simpler than trying to recreate the UNIX auto-config behaviour on Windows, because Windows just isn't very robust that way.
The easiest way would be to have the installer auto-detect compilers on
your
machine and allow the user to edit the list, adding/modifying compilers as they need, then select which ones they want to build the libraries for. It should be possible to build again at a later stage when you add a new compiler, etc.
That's precisely not the easy thing. It saves download time, but costs complexity, and worse, when things fail, they fail far away from the expert who constructed the auto-detect algorithm. So, you end out with a frustrated expert and a frustrated user. It's the customer support issue. You want to mimimize the complexity of what executes on the client, so that less can go wrong.
Granted, this could make the install take a long time (if you are
supporting
many different compilers), but the user should be able to (optionally) see the output and provide a way of estimating how long the build phase will take (so the user knows that they can come back in an hour or whatever).
An installer like ths could be intelligent enough to extract and/or build only the ilbraries you want, for example, you could just build the Filesystem library.
That way we sidestep the whole issue of using JAM. This has two benefits: - Windows programmers expect to be able to click on a link and simply download the answer. - Windows programmers would get a reliable library that was built under controlled circumstances. We'd all spend less time supporting folks who have trouble driving the compiler via JAM, and/or who have somehow produced a corrupt boost library.
What if you install a library for VC6.5 and you only have VC6.0? Building a project could then break when you link against the 6.5 versions.
Personally, I did use JAM successfully, but I also encountered a number of error messages that I quickly worked through, and didn't think much about. It would have been a barrier to someone less experienced though, and we don't want that.
The install/build GUI could process this so that it generates a friendlier summary informing you of what broke.
Reece Haston Dunn Software Engineer, Sophos
Web: www.sophos.com Sophos - protecting businesses against viruses and spam
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Robert Mathews" <rmathews@envoyww.com> writes:
And all programming shops I've been to pick a particular compiler, programming model, and then stick with it, so the following idea should work:
So, what you'd do it is write a installer stub that 1) queried for compiler model 2) queried for compile model (single threaded, multithreaded, static, dll etc)
And then took that information and went off and downloaded the correct library.
Probably that makes too many prebuilt libs for Boost to build, test, make available, and support. I don't know of any open-source project that supports 50+ platforms in 4 configurations with binaries.
Seems simply enough to me. Much simpler than trying to recreate the UNIX auto-config behaviour on Windows, because Windows just isn't very robust that way.
Can you implement it? ;-)
The easiest way would be to have the installer auto-detect compilers on your machine and allow the user to edit the list, adding/modifying compilers as they need, then select which ones they want to build the libraries for. It should be possible to build again at a later stage when you add a new compiler, etc.
That's precisely not the easy thing. It saves download time, but costs complexity, and worse, when things fail, they fail far away from the expert who constructed the auto-detect algorithm. So, you end out with a frustrated expert and a frustrated user.
The user will also have problems with prebuilt libraries when he tries to use them in his project that has a different, incompatible configuration.
It's the customer support issue. You want to mimimize the complexity of what executes on the client, so that less can go wrong.
I think there are several sides to this polyhedron. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Robert Mathews <rmathews@envoyww.com> wrote:
[...] On my machine, the compiled libraries + source (no object files) takes 700MB for all the models for VC71. But, that's uncompressed. Compressed is a different story.
When I compress my directory, I get a 90% reduction in size - more like 70MB. But that's still too large. However, a single compile model - ie, single threaded (debug+release) - takes only 4.6MB, which is easily downloadable.
We use boost libs to write software for a living. We all sit on machines that are permanently connected to the internet. If it saves three hours of a developer's work the boss certainly rather has us download 700MB. Actually, knowing my boss, I think he'd rather has us download 7/GB/ and work on something else instead for those three hours. <g> I find it a PITA to download 4.6MB over ISDN from home. But at work, I'd download everything "just in case" and look at it later.
[...]
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
On Wed, May 25, 2005 at 03:46:25PM +0200, Hendrik Schober wrote:
...found 4471 targets... ...updating 1123 targets... ...can't find 2 targets... Um, what are targets? Why does it only "update" a quarter of them? Why wouldn't it find 2 of them? I read the guide again. Damn! I messed this up! I need to pass "vc", not "VC71_ROOT"! The guid is a bit terse in that area...
Terse, but quite accurate: Invoke the build system, specifying the toolset(s) you wish to use, to build and install. For example for GNU/GCC. bjam "-sTOOLS=gcc" install Where "toolset" is a link to the table of toolset names. Neither "vc" nor "VC71_ROOT" is in that table. I don't like bjam much, and I don't think users should have to use the command line, but I do think reading instructions is a reasonable requirement ;) jon
Jonathan Wakely <cow@compsoc.man.ac.uk> wrote:
[...] Terse, but quite accurate:
I wouldn't doubt its accuracy. It's just that I needed to read it two times to understand it. (And I surely benefit from reading here since long before bjam got discussed.)
Invoke the build system, specifying the toolset(s) you wish to use, to build and install. For example for GNU/GCC.
bjam "-sTOOLS=gcc" install
Where "toolset" is a link to the table of toolset names. Neither "vc" nor "VC71_ROOT" is in that table.
Mhmm. I re-read it. The first thing I stumbled over was #3, where it says: "The following toolsets are supported by Boost.Build. For information about configuring each toolset, click its name in the leftmost column." I picked mine and there was a variable name shown. So I copied this...
I don't like bjam much, and I don't think users should have to use the command line, but I do think reading instructions is a reasonable requirement ;)
...of course, I could have read more thouroughly. But that was the OP's point: It just takes too much effort to be named custom friendly.
jon
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
But if this was my first look at boost, I'd delete it right away. Seriously, on this platform are millions of C++ users that only heard very vague rumours of C++ being standardized -- if they heard about it at all. Those don't see much benefit it smart pointers, consider the MPL to be black art, and can't be bothered if it isn't really easy to use.
Schobi
--
But for these "millions of C++ users" Boost is not the right choice. The exciting thing about Boost is that it is Avantgarde, a good deal of interesting research(!), and not compromising on quality. That's at least my understanding of Boost. Sure, it would be nice to have this additional layer for beginners, but that simply seems not to be feasible. Sure, documentation of Boost can be improved (and the installation guides as far as I know them are really not enough (I say this as a Linux user)), but that's true for ALL existing software. It's just hard to write about technical material, and, as I know it from our students, for example almost all computer science students have to be considered as near analphabets, so it's not so easy to get the documentation written. (But GUI's are at the root of that problem: They destroy understanding.) Here comes one proposal: If it would be easier for boost members to edit existing documentation, then at least I could contribute quite a bit. But I mean "really easy", for example a wiki with the current documentation, where one can just goes and change it (and there is somebody responsible for each (sub-)library); this could really improve documentation a lot. (One should have as a general guideline, that additions are conservative, that is, they only extend and correct the given text, but they do not eliminate something (because one doesn't like the style etc.). And my focus here is really on the *text*, which quite often assumes some common ground, which more often than not is not given.) Here one example (about documentation in general): I know of one MSc project of a colleague, based on Spirit, which nearly failed because the student didn't have the right understanding what Spirit really was supposed to do (that "recursive decent parser thing"), and also I fall into the same trap (but it only cost me a few hours). So an easy thing would be to go to the *current* Spirit documentation, and add at one or two places a few warnings. This could help a lot. But first writing an e-mail, explaining all this, etc. costs too much time. Just adding these sentences on a wiki, that should be it, and the maintainer then is automatically alerted. Oliver
Oliver Kullmann <O.Kullmann@swansea.ac.uk> wrote:
[...] But for these "millions of C++ users" Boost is not the right choice. The exciting thing about Boost is that it is Avantgarde, a good deal of interesting research(!), and not compromising on quality. That's at least my understanding of Boost.
Mine is different. Boost contains many things that should have been in the std lib to begin with. I want these things to be widely used, so that I don't have to deal with so much bad code. Who should use smart pointers if not those who aren't avantgarde??? (AFAIK, boost is distrubuted as part of the Indesign SDK. You won't reuire all Indesign plugin developers to be avantgarde, will you?)
[...] Oliver
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
Ditto, I completely agree with everything below... On 25 May 2005, at 16:02, Oliver Kullmann wrote:
But if this was my first look at boost, I'd delete it right away. Seriously, on this platform are millions of C++ users that only heard very vague rumours of C++ being standardized -- if they heard about it at all. Those don't see much benefit it smart pointers, consider the MPL to be black art, and can't be bothered if it isn't really easy to use.
Schobi
--
But for these "millions of C++ users" Boost is not the right choice. The exciting thing about Boost is that it is Avantgarde, a good deal of interesting research(!), and not compromising on quality. That's at least my understanding of Boost.
Sure, it would be nice to have this additional layer for beginners, but that simply seems not to be feasible.
Sure, documentation of Boost can be improved (and the installation guides as far as I know them are really not enough (I say this as a Linux user)), but that's true for ALL existing software. It's just hard to write about technical material, and, as I know it from our students, for example almost all computer science students have to be considered as near analphabets, so it's not so easy to get the documentation written. (But GUI's are at the root of that problem: They destroy understanding.)
I think some people seem to see me as anti GUI / pro command line. You've hit the nail on the head. GUI's seem to destroy understanding. I can't bear using GUI's for most of the web programming because it just tries to hide too much. At the same time tools like vi are just anti productive to my work due to the learning curve. A simplified build process is what's needed
Here comes one proposal: If it would be easier for boost members to edit existing documentation, then at least I could contribute quite a bit. But I mean "really easy", for example a wiki with the current documentation, where one can just goes and change it (and there is somebody responsible for each (sub-)library); this could really improve documentation a lot. (One should have as a general guideline, that additions are conservative, that is, they only extend and correct the given text, but they do not eliminate something (because one doesn't like the style etc.). And my focus here is really on the *text*, which quite often assumes some common ground, which more often than not is not given.)
Here one example (about documentation in general): I know of one MSc project of a colleague, based on Spirit, which nearly failed because the student didn't have the right understanding what Spirit really was supposed to do (that "recursive decent parser thing"), and also I fall into the same trap (but it only cost me a few hours). So an easy thing would be to go to the *current* Spirit documentation, and add at one or two places a few warnings. This could help a lot. But first writing an e-mail, explaining all this, etc. costs too much time. Just adding these sentences on a wiki, that should be it, and the maintainer then is automatically alerted.
A wiki would be excellent. One of the nice thing I like about the PHP documentation is that users have added comments over the years stating various gotchas they've experienced.
Oliver
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think some people seem to see me as anti GUI / pro command line. You've hit the nail on the head. GUI's seem to destroy understanding. I can't bear using GUI's for most of the web programming because it just tries to hide too much. At the same time tools like vi are just anti productive to my work due to the learning curve. A simplified build process is what's needed
All this really just doesn't seem relevent to anything at all that I can see. Surely we all learnt long ago that whats good for one person is not neccessarily good for another. You wanna build via command line, fine do so (i do). Some people don't want to, someone has offered to help try and plug this gap so maybe he should be just taken up on the offer;) Telling people to do it your way or no way is pretty much guaranteed to get a lot of people doing it no way and ignoring it entirely. A very simple utility such as the one John Torjo ships with win32gui to build it (simply a dialog that does the right thing when the user presses the button next to the compiler they are using) would go a long way to address all of these issues in probably under a hundred lines of code. Obviously not absolutely ideal (selecting libraries to build immediately suggests itself and consideration for cross platformness) but possibly a good enough starting point. Martin -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 266.11.16 - Release Date: 24/05/2005
Jason Earl <Jason@hybd.net> wrote:
[...] You've hit the nail on the head. GUI's seem to destroy understanding. [...]
So do automatic gears. Are they bad, too?
[...] At the same time tools like vi are just anti productive to my work due to the learning curve.
So you know that, too: What you don't use often enough, requires too steep a learning curve and therefor is in danger of being avoided.
A simplified build process is what's needed
There's nothing easier than hitting F7 in my IDE. <g>
[...]
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
At 08:42 2005-05-25, Hendrik Schober wrote:
Jason Earl <Jason@hybd.net> wrote:
[...] You've hit the nail on the head. GUI's seem to destroy understanding. [...]
So do automatic gears. Are they bad, too?
[...] At the same time tools like vi are just anti productive to my work due to the learning curve.
So you know that, too: What you don't use often enough, requires too steep a learning curve and therefor is in danger of being avoided.
A simplified build process is what's needed
There's nothing easier than hitting F7 in my IDE. <g>
AFTER you've set up all the options you want for the particular build you're playing with right now. do you have ANY idea how many different flavors of libraries exist for your IDE?
[...]
Schobi
-- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving" Terry Pratchett
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. <vawjr@rudbek.com> wrote:
[...]
A simplified build process is what's needed
There's nothing easier than hitting F7 in my IDE. <g>
AFTER you've set up all the options you want for the particular build you're playing with right now.
Right. That's why a ready-made project file would be the simplest for most users. They add it to their solution, update dependencies, assign the project's configurations to solution configurations, and are done.
do you have ANY idea how many different flavors of libraries exist for your IDE?
Yes. We're distributing libs.
[...] Victor A. Wagner Jr. http://rudbek.com
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
Oliver Kullmann <O.Kullmann@swansea.ac.uk> writes:
But for these "millions of C++ users" Boost is not the right choice.
It should be.
The exciting thing about Boost is that it is Avantgarde, a good deal of interesting research(!), and not compromising on quality. That's at least my understanding of Boost.
We don't want to be Avantgarde/research; to the extent that we are, we need to fix it.
Sure, it would be nice to have this additional layer for beginners, but that simply seems not to be feasible.
It is certainly feasible. We just need to know what to do, and allocate the resources to do it.
Here comes one proposal: If it would be easier for boost members to edit existing documentation, then at least I could contribute quite a bit. But I mean "really easy", for example a wiki with the current documentation, where one can just goes and change it (and there is somebody responsible for each (sub-)library); this could really improve documentation a lot.
Or it could result in the documentation getting a lot worse. I certainly have seen incorrect advice posted often enough about Boost.Python that I don't want even some experienced Boost.Python users to change the official documentation without getting a chance to review the changes first.
(One should have as a general guideline, that additions are conservative, that is, they only extend and correct the given text, but they do not eliminate something (because one doesn't like the style etc.). And my focus here is really on the *text*, which quite often assumes some common ground, which more often than not is not given.)
Even adding information to existing text can make it worse. But anyone motivated to make significant contributions to the documentation can probably get CVS write access, which is IMO easier to use than a Wiki for any substantial writing where you have to edit in a browser window or copy/past back and forth.
Here one example (about documentation in general): I know of one MSc project of a colleague, based on Spirit, which nearly failed because the student didn't have the right understanding what Spirit really was supposed to do (that "recursive decent parser thing"), and also I fall into the same trap (but it only cost me a few hours). So an easy thing would be to go to the *current* Spirit documentation, and add at one or two places a few warnings. This could help a lot. But first writing an e-mail, explaining all this, etc. costs too much time. Just adding these sentences on a wiki, that should be it, and the maintainer then is automatically alerted.
Well, that's an interesting idea. But it would take a *lot* of work to set up. Do you think enough people would be motivated to edit the documentation that it would be worth the effort? As you say, "it's not so easy to get the documentation written," which is in part because people don't like writing docs. Hmm, a QuickBook documentation Wiki... it has a certain ring to it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Oliver Kullmann <O.Kullmann@swansea.ac.uk> writes:
But for these "millions of C++ users" Boost is not the right choice.
It should be.
Oliver was talking about those millions of C++ users that "see no benefit in smart pointers", "see MPL as black art" etc. Right, Oliver? I really hope that Boost will not try to fit the needs of those less experienced developers, since that will, IMHO, inevitably make the library less useful for those of us who actually do type "make -k" now and then...
The exciting thing about Boost is that it is Avantgarde, a good deal of interesting research(!), and not compromising on quality. That's at least my understanding of Boost.
We don't want to be Avantgarde/research; to the extent that we are, we need to fix it.
I agree with that, unless one replaces the "Avantgarde/research" with "for experts." I.e., I want Boost to remain a choice for C++ experts. Most of those "millions of C++ users" that Oliver is refering to are actually quite junior C developers who have been forced to use some C++ keywords and OOP in order to exploit MFC instead of raw Win32 programming. And those developers already have MFC and ATL, and would probably only use 'shared_ptr' from Boost. What I am saying is that it would not be unreasonable to expect the targeted developers to actually type 'bjam', and perhaps even set the proper environment variables. I do not think we have to flirt with the masses - developers that would not use the facilities found in Boost anyway - in order to position it better for incorporation into future C++ standardizations. /David Bergman
"David Bergman" <davidb@home.se> writes:
David Abrahams wrote:
Oliver Kullmann <O.Kullmann@swansea.ac.uk> writes:
But for these "millions of C++ users" Boost is not the right choice.
It should be.
Oliver was talking about those millions of C++ users that "see no benefit in smart pointers", "see MPL as black art" etc. Right, Oliver? I really hope that Boost will not try to fit the needs of those less experienced developers, since that will, IMHO, inevitably make the library less useful for those of us who actually do type "make -k" now and then...
The usefulness of smart pointers and MPL for people has no correlation with whether they feel comfortable with make -k
The exciting thing about Boost is that it is Avantgarde, a good deal of interesting research(!), and not compromising on quality. That's at least my understanding of Boost.
We don't want to be Avantgarde/research; to the extent that we are, we need to fix it.
I agree with that, unless one replaces the "Avantgarde/research" with "for experts." I.e., I want Boost to remain a choice for C++ experts.
We never wanted to be the sole province of experts. We always wanted widespread usage. If you want to be a member of an exclusive "experts" club this is the wrong place to find it.
Most of those "millions of C++ users" that Oliver is refering to are actually quite junior C developers who have been forced to use some C++ keywords and OOP in order to exploit MFC instead of raw Win32 programming.
Yes.
And those developers already have MFC and ATL, and would probably only use 'shared_ptr' from Boost.
That's a good start.
What I am saying is that it would not be unreasonable to expect the targeted developers to actually type 'bjam', and perhaps even set the proper environment variables.
It would be unreasonable for some of them. I've worked with quite advanced and competent developers who are only comfortable in an IDE.
I do not think we have to flirt with the masses
Too late ;-)
- developers that would not use the facilities found in Boost anyway - in order to position it better for incorporation into future C++ standardizations.
Yes, we do. We need maximal adoption in order to be best positioned for standardization. Not just to get the libraries accepted, but also so they are really deserving of standardization. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes: | We never wanted to be the sole province of experts. We always wanted | widespread usage. If you want to be a member of an exclusive | "experts" club this is the wrong place to find it. Sure. But there, imho, must be a difference expected between _users_ of the libraries, and _installers_ (or packagers) of the libraries. -- Lgb
Lars Gullik Bjønnes <larsbj@gullik.net> wrote:
David Abrahams <dave@boost-consulting.com> writes:
| We never wanted to be the sole province of experts. We always wanted | widespread usage. If you want to be a member of an exclusive | "experts" club this is the wrong place to find it.
Sure. But there, imho, must be a difference expected between _users_ of the libraries, and _installers_ (or packagers) of the libraries.
How so? Shall people employ an administrator to install the libs they want to check out? Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
"Hendrik Schober" <SpamTrap@gmx.de> writes: | Lars Gullik Bjønnes <larsbj@gullik.net> wrote:
David Abrahams <dave@boost-consulting.com> writes:
| We never wanted to be the sole province of experts. We always wanted | widespread usage. If you want to be a member of an exclusive | "experts" club this is the wrong place to find it.
Sure. But there, imho, must be a difference expected between _users_ of the libraries, and _installers_ (or packagers) of the libraries.
| How so? Shall people employ an administrator to | install the libs they want to check out? No. But IMHO it should be expect that it is a bit harder to install (and in this case it is build as well) the library than use it. So: Create an windows installer and then the user can use that. -- Lgb
David Abrahams wrote:
"David Bergman" <davidb@home.se> writes:
David Abrahams wrote:
Oliver Kullmann <O.Kullmann@swansea.ac.uk> writes:
[snip...]
The exciting thing about Boost is that it is Avantgarde, a
good deal of interesting research(!), and not compromising on
quality. That's at least my understanding of Boost.
Boost only is so by the extent of its reach/familarity - ie it really is a matter of exposure; any other consideration of Boost is really a matter perception. What is exciting about Boost is the exploration into new avenues - the overwhelming desire to do better, and chart unexplored teritory; the MPL, Fusion or the Boost.PP are such examples; and then there is the level of quality output and constant peer review - discussions beyond the text book. -That's what makes Boost exciting.
We don't want to be Avantgarde/research; to the extent that we are, we need to fix it.
I agree with that, unless one replaces the "Avantgarde/research" with "for experts." I.e., I want Boost to remain a choice for C++ experts.
I believe the waters have become muddied here - I'm going to go out on a limb here and hazard a guess that the intended statement was that we don't want to compramise on the quality of Boost - and I don't think that will ever happen. To an extent, the Boost community is a collective for the advancement of the language (whence research), and a worthy advocate and signpost to the rest of the world to advertise the worth of the language - our signposts just need to be bigger - otherwise Boost withers.
We never wanted to be the sole province of experts. We always wanted widespread usage. If you want to be a member of an exclusive "experts" club this is the wrong place to find it.
Agreed. If Boost were ever to be the province of experts it would defeat its very purpose - namely to grow and flourish throughout the C++ community; to be an example and a leader in modern C++ method, design, and direction.
[snip...]
What I am saying is that it would not be unreasonable to expect the targeted developers to actually type 'bjam', and perhaps even set the proper environment variables.
It would be unreasonable for some of them. I've worked with quite advanced and competent developers who are only comfortable in an IDE.
I sympathize. I only work on the command line (Unix / Linux). I could never work with an IDE, and if I had too I'd be lost - so in the same vein, I am sure those not comfortable with command line tools are just as lost as I, when set in front of an IDE. -Boost needs to better cater for their needs, it's a sad reality, but too many coders out there don't live on the command line.
I do not think we have to flirt with the masses
Too late ;-)
Indeed ;-) And again I stress, if we don't Boost dies - and none of us wants that.
- developers that would not use the facilities found in Boost anyway - in order to position it better for incorporation into future C++ standardizations.
Yes, we do. We need maximal adoption in order to be best positioned for standardization. Not just to get the libraries accepted, but also so they are really deserving of standardization.
Again, well said. my $0.02 Cheers, -- Manfred Doudar MetOcean Engineers www.metoceanengineers.com
David Abrahams wrote:
I agree with that, unless one replaces the "Avantgarde/research" with "for experts." I.e., I want Boost to remain a choice for C++ experts.
We never wanted to be the sole province of experts. We always wanted widespread usage. If you want to be a member of an exclusive "experts" club this is the wrong place to find it.
I do not want to be a member of an "experts" club, I want a set of tools that actually fit a highly experienced developer. It just might be that such a toolset would not fit the less experienced one. If Boost can fit the whole spectrum, great By the way, I think there indeed is a correlation between "make -k"/"bjam"-adaptable developers and those using the most complex portions of Boost.
Most of those "millions of C++ users" that Oliver is refering to are actually quite junior C developers who have been forced to use some C++ keywords and OOP in order to exploit MFC instead of raw Win32 programming.
Yes.
And those developers already have MFC and ATL, and would probably only use 'shared_ptr' from Boost.
That's a good start.
Agreed, and that is usually the way that I sneak Boost into the "mainstream" developer's vocabulary.
What I am saying is that it would not be unreasonable to expect the targeted developers to actually type 'bjam', and perhaps even set the proper environment variables.
It would be unreasonable for some of them. I've worked with quite advanced and competent developers who are only comfortable in an IDE.
But they sure would be able to change one or two environment variables and type 'bjam', right?
I do not think we have to flirt with the masses
Too late ;-)
- developers that would not use the facilities found in Boost anyway - in order to position it better for incorporation into future C++ standardizations.
Yes, we do. We need maximal adoption in order to be best positioned for standardization. Not just to get the libraries accepted, but also so they are really deserving of standardization.
The risk is that Boost will inevitably belong to those 50% of the C++ standard that is never touched by most developers, ever. None of the "C++ experts" I have interviewed for employment has heard of the keyword 'typename' or used template template parameters, or used 'virtual' base classes. That does not mean that I will stop preaching Boostness for all C++ developers I meet. Heck, I even try to promote Lambda and MPL, so you are probably right, Mr. Abrahams. Boost actually might help reunifying C++ again, instead of constituting two languages, one for MFC:ers (I have developed a lot of MFC apps myself, so do not take the label literally) and one for "experts", which it does today, IMEHO. /David Bergman
David Bergman <davidb@home.se> wrote:
[...] By the way, I think there indeed is a correlation between "make -k"/"bjam"-adaptable developers and those using the most complex portions of Boost.
[...] I've worked with
quite advanced and competent developers who are only comfortable in an IDE.
But they sure would be able to change one or two environment variables and type 'bjam', right?
[...]
The risk is that Boost will inevitably belong to those 50% of the C++ standard that is never touched by most developers, ever. None of the "C++ experts" I have interviewed for employment has heard of the keyword 'typename' or used template template parameters, or used 'virtual' base classes.
[...] Boost actually might help reunifying C++ again, instead of constituting two languages, one for MFC:ers [...] and one for "experts", which it does today, IMEHO.
Just for some background: We are using more than two dozen 3rd-party SDKs and libraries, both free software and commercial ones, some across almost half a dozen platforms. We are using boost since 2001. I have never written an MFC app. Not a single one. (Of a dozen or so developers here, I know one who has for some toy projects.) I am considered the "C++ expert" here and people often are annoyed that I am forcing them to learn where 'typename' is required, how template template parameters are working, and what these 4k error messages from template meta code mean. :^> (I would suppose everyone here knows what virtual bases are for.) I have failed to build/install boost without putting considerably more effort into it than I needed to put into many other libraries. That is, I was unable to just download it and check it out. I think this would be the same with most Win/Mac developers here.
/David Bergman
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
"David Bergman" <davidb@home.se> writes:
David Abrahams wrote:
I agree with that, unless one replaces the "Avantgarde/research" with "for experts." I.e., I want Boost to remain a choice for C++ experts.
We never wanted to be the sole province of experts. We always wanted widespread usage. If you want to be a member of an exclusive "experts" club this is the wrong place to find it.
I do not want to be a member of an "experts" club, I want a set of tools that actually fit a highly experienced developer. It just might be that such a toolset would not fit the less experienced one. If Boost can fit the whole spectrum, great
By the way, I think there indeed is a correlation between "make -k"/"bjam"-adaptable developers and those using the most complex portions of Boost.
I think you'd be surprised at how many even of the advanced Boost developers don't really understand Boost.Build. It's most of us. It's not just a question of what you could, theoretically, adapt to. It's also a question of what you have time to learn. For Boost developers, we have to make learning Boost.Build easier, but it is still going to be a hump for them to get over. For everyone else, the incentives are a bit lower -- we may need to provide other means to that end.
What I am saying is that it would not be unreasonable to expect the targeted developers to actually type 'bjam', and perhaps even set the proper environment variables.
It would be unreasonable for some of them. I've worked with quite advanced and competent developers who are only comfortable in an IDE.
But they sure would be able to change one or two environment variables and type 'bjam', right?
Yes, but they really don't like it. And it doesn't fit into their development model. It's uncomfortable, and thus a disincentive to using Boost.
I do not think we have to flirt with the masses
Too late ;-)
- developers that would not use the facilities found in Boost anyway - in order to position it better for incorporation into future C++ standardizations.
Yes, we do. We need maximal adoption in order to be best positioned for standardization. Not just to get the libraries accepted, but also so they are really deserving of standardization.
The risk is that Boost will inevitably belong to those 50% of the C++ standard that is never touched by most developers, ever.
?? Boost will belong to some portion of the C++ standard ?? I have no clue what you're getting at.
None of the "C++ experts" I have interviewed for employment has heard of the keyword 'typename' or used template template parameters, or used 'virtual' base classes.
That does not mean that I will stop preaching Boostness for all C++ developers I meet. Heck, I even try to promote Lambda and MPL, so you are probably right, Mr. Abrahams. Boost actually might help reunifying C++ again, instead of constituting two languages, one for MFC:ers (I have developed a lot of MFC apps myself, so do not take the label literally) and one for "experts", which it does today, IMEHO.
Well, I hope so, anyway. That's what good libraries *should* do. -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 03:41 2005-05-26, David Bergman wrote: [deleted]
The risk is that Boost will inevitably belong to those 50% of the C++ standard that is never touched by most developers, ever. None of the "C++ experts" I have interviewed for employment has heard of the keyword 'typename' or used template template parameters, or used 'virtual' base classes.
I "hang out" (too much, according to my wife) on undernet in the #C++ channel. The state of teaching C++ is northing short of abysmal (either that or kids (c'mon, I'm 62 in 3 weeks; all you guys are "kids") in schools just aren't interested in learning.... I opt for teachers who can't tell their * from a hole in the ground). Near as I can tell, many universities are graduating folks that have maybe 2 weeks exposure to the STL !!! If we can't even get college graduates who know what the _standard_ library contains, how are we going to convince them they ought to look at a "3rd party" library. BTW, I think calling it "the boost library" is occasionally misleading. I've taken to calling it a library collection (yeah, I know what the word library really means, apparently we don't teach the language (american english) very well here in the U.S.) just to try to get around the "It's too big" complaint.
That does not mean that I will stop preaching Boostness for all C++ developers I meet. Heck, I even try to promote Lambda and MPL, so you are probably right, Mr. Abrahams. Boost actually might help reunifying C++ again, instead of constituting two languages, one for MFC:ers (I have developed a lot of MFC apps myself, so do not take the label literally) and one for "experts", which it does today, IMEHO.
/David Bergman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
David Abrahams wrote:
Yes, we do [need to flirt with the masses...]. We need maximal adoption in order to be best positioned for standardization. Not just to get the libraries accepted, but also so they are really deserving of standardization.
Ok, so what can I do to assist in this effort? More concretely, what kind of installer are we talking about? I would like for us to have an installer-generator (for Windows) so we do not have to recreate, or at least rebuild, the installer for every revision of Boost. /David Bergman
"David Bergman" <davidb@home.se> writes:
David Abrahams wrote:
Yes, we do [need to flirt with the masses...]. We need maximal adoption in order to be best positioned for standardization. Not just to get the libraries accepted, but also so they are really deserving of standardization.
Ok, so what can I do to assist in this effort? More concretely, what kind of installer are we talking about?
Well, to begin with I think we need a Windows installer for headers and vc7.1 binaries. There are some free pro-quality installer construction systems for Windows out there; I forget the names though. There are a number of valuable possible enhancements I can think of, if you're ambitious: - Allow users to select which libraries they want and: a. use bcp to allow users to cut down how much is actually installed, or b. allow people to cut down how much is actually downloaded (a la cygwin installer) - Add support for binaries for other compilers, although especially when you add STLPort in as a variable there are just too many libs to build to get complete coverage, so: - add support for invoking bjam via a GUI. Preferably this GUI would dynamically show the user the bjam command-line it is composing so that the user would gain some familiarity and be able to step outside the bounds of the GUI eventually.
I would like for us to have an installer-generator (for Windows) so we do not have to recreate, or at least rebuild, the installer for every revision of Boost.
Sounds good. Thanks for volunteering! -- Dave Abrahams Boost Consulting www.boost-consulting.com
I recommend looking here: http://sourceforge.net/projects/wix/ "The Windows Installer XML (WiX) is a toolset that builds Windows installation packages from XML source code. The toolset supports a command line environment that developers may integrate into their build processes to build MSI and MSM setup packages " Theroeticially you could build a simple C++ application that could generate the XML file which includes dependencies between libraries and then create MSM setup packages. Then you could chop and choose what you would like to install. A really good tutorial is here: http://www.tramontana.co.hu/wix/ Taken from the tutorial introduction: ---------- The toolset we are about to introduce, WiX, uses a different approach. Instead of a tool with a graphical interface that allows the developers to collect the files and other related tasks making up the installation process manually, it is much more like a programming language. Integrating perfectly with the usual process of creating applications, it uses a text file (based on the increasingly popular XML format) to describe all the elements of the installation process. The toolset has a compiler and a linker that will create the setup program just like our usual compiler creates our application from the source files. Therefore, WiX can be made part of any automated application build process very easily, be that based either on the classical technology of makefiles or the similar features of contemporary integrated development environments. In addition to this integration, providing basically nothing more but developer comfort, WiX offers another level of integration, far more advantageous than the first one: the integration of the setup development process with that of the application. Traditionally, setup programs were only written when the main application had already been finished; often even by different developers. This approach requires a tedious and error prone process of collecting information about all the resources making up the application. While the files themselves are usually obvious, registry entries, services and most forms of inter-resource dependencies are often hard to reconstruct in a later stage: if solid development documentation is lacking, the setup developers have to collect all pieces of information from the original developers or try to extract it from the source code. In an integrated application/setup development environment, the original developer should modify the WiX source files in sync with the application development. As soon as a new module has been started, a new registry, service or other dependency has been coded, the appropriate setup modification should be made in parallel. Using this approach, no important information will ever be lost and, as a bonus, the setup program will be practically finished together with application itself. ---------- The for a blog with the original developer is here: http://blogs.msdn.com/robmen/default.aspx Peter. ----- Original Message ----- From: "David Abrahams" <dave@boost-consulting.com> Newsgroups: gmane.comp.lib.boost.devel Sent: Friday, May 27, 2005 12:21 AM Subject: Re: Customer Friendlier Boost Installation
"David Bergman" <davidb@home.se> writes:
Well, to begin with I think we need a Windows installer for headers and vc7.1 binaries. There are some free pro-quality installer construction systems for Windows out there; I forget the names though.
There are a number of valuable possible enhancements I can think of, if you're ambitious:
- Allow users to select which libraries they want and:
a. use bcp to allow users to cut down how much is actually installed, or
b. allow people to cut down how much is actually downloaded (a la cygwin installer)
- Add support for binaries for other compilers, although especially when you add STLPort in as a variable there are just too many libs to build to get complete coverage, so:
- add support for invoking bjam via a GUI. Preferably this GUI would dynamically show the user the bjam command-line it is composing so that the user would gain some familiarity and be able to step outside the bounds of the GUI eventually.
I would like for us to have an installer-generator (for Windows) so we do not have to recreate, or at least rebuild, the installer for every revision of Boost.
Sounds good. Thanks for volunteering!
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 25/05/05, David Bergman <davidb@home.se> wrote:
Oliver Kullmann <O.Kullmann@swansea.ac.uk> writes:
But for these "millions of C++ users" Boost is not the right choice. It should be. Oliver was talking about those millions of C++ users that "see no benefit in smart pointers", "see MPL as black art" etc. Right, Oliver? I really hope
David Abrahams wrote: that Boost will not try to fit the needs of those less experienced developers, since that will, IMHO, inevitably make the library less useful for those of us who actually do type "make -k" now and then...
While some people may end up using a library inappropriately, I honestly don't see how a static, unchanging piece of code magically "gets worse" as more people use it.
I agree with that, unless one replaces the "Avantgarde/research" with "for experts." I.e., I want Boost to remain a choice for C++ experts.
To me, an Expert is someone who is both Experienced AND Smart. And the smartest people I know do their absolute best at helping the people around them be smarter, because, among other reasons, that helps them get smarter. How else can you ever breed new experts?
Most of those "millions of C++ users" that Oliver is refering to are actually quite junior C developers who have been forced to use some C++ keywords and OOP in order to exploit MFC instead of raw Win32 programming.
They need to start somewhere.
And those developers already have MFC and ATL, and would probably only use 'shared_ptr' from Boost.
That is a great beginning. Once developers get more experienced using shared_ptrs, their designs get better, as they begin to address resource ownership issues. They get smarter. Another simple library they can start using is boost::noncopyable. As they get more experienced, their designs differentiate between classes with value semantics and classes with reference semantics. They get smarter.
What I am saying is that it would not be unreasonable to expect the targeted developers to actually type 'bjam', and perhaps even set the proper environment variables.
I totally disagree. We need to remove every barrier of entry we possibly can. There is nothing about understanding 'bjam' or any arcane command line (or arcane mouse clicks in a badly designed GUI, for that matter) that helps someone be a better C++ programmer.
I do not think we have to flirt with the masses - developers that would not use the facilities found in Boost anyway - in order to position it better for incorporation into future C++ standardizations.
Without the masses programming in C++, the standardization effort won't matter, because C++ will be dead. The STL was the first library I've seen in any language that helped developers be smarter. Once adopted (usually kicking and screaming), the folks who use it write smaller, more robust, more understandable code. And they are enjoying it more. Their designs are no longer drowning in a sea of details. They are smarter. I see much of the stuff in Boost helping people along that path. Experts don't hoard good libraries for themselves; real experts do whatever it takes to get other developers to understand and embrace those libraries so that we are all writing better code and are all journeying towards being experts ourselves. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (773) 961-1620
David Bergman <davidb@home.se> wrote:
David Abrahams wrote:
Oliver Kullmann <O.Kullmann@swansea.ac.uk> writes:
But for these "millions of C++ users" Boost is not the right choice.
It should be.
Oliver was talking about those millions of C++ users that "see no benefit in smart pointers", "see MPL as black art" etc. [...]
I would like to see boost especially appeal to those.
[...] I want Boost to remain a choice for C++ experts.
IIRC, boost was founded as a means to play with what should go into the next std lib. IMHO the std lib isn't only for experts, but for everyone. So should be boost.
Most of those "millions of C++ users" that Oliver is refering to are actually quite junior C developers who have been forced to use some C++ keywords and OOP in order to exploit MFC instead of raw Win32 programming. And those developers already have MFC and ATL, and would probably only use 'shared_ptr' from Boost.
Good start! That's how I sneaked boost in here: I demonstrated a bug in the home-grown smart pointer and pleaded for using boost's.
What I am saying is that it would not be unreasonable to expect the targeted developers to actually type 'bjam', and perhaps even set the proper environment variables.
If they are targeted, and it's unreasonable to expect this from them, it should be made easier.
I do not think we have to flirt with the masses - developers that would not use the facilities found in Boost anyway - in order to position it better for incorporation into future C++ standardizations.
I very strongly disagree.
/David Bergman
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
On 5/25/05, Hendrik Schober <SpamTrap@gmx.de> wrote:
Caleb Epstein <caleb.epstein@gmail.com> wrote:
[...] I really think the Getting Started guide is more than adequate, and is concise and easy to follow. There are gigantic yellow numbers next to the important steps. [...] really how much more hand-holding does one need?
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
No, thats not at all what the guide says. You type: ..\bjam.exe -sTOOLS=vc-7_1 stage Where did you get VC71_ROOT from?
After quite a pause ("what's it doing now?") it spit out a lengthy messagethat that I have an incorrect configuration. It couldn't find Python.
This is only pertinent if you are building Boost.Python.
Mhmm. Do I need this? Will it even work without Python? (I know it will. But not from the guide.) Next thing it emits is don't know how to make bjam
Because you typed bjam twice on the command line
[etc]
Just follow the directions. They could be more clearly written, but you haven't even come close to typing equivalent commands to the ones listed on the Getting Started page. Admittedly there should be example command lines for vc-7_1 etc and not just gcc. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein <caleb.epstein@gmail.com> wrote:
[...] No, thats not at all what the guide says. You type:
..\bjam.exe -sTOOLS=vc-7_1 stage
Wow. No warning. Thanks!
Where did you get VC71_ROOT from?
I explained this in another mail.
After quite a pause ("what's it doing now?") it spit out a lengthy messagethat that I have an incorrect configuration. It couldn't find Python.
This is only pertinent if you are building Boost.Python.
As I said: /I/ knew this. But many who stumble over boost don't.
Mhmm. Do I need this? Will it even work without Python? (I know it will. But not from the guide.) Next thing it emits is don't know how to make bjam
Because you typed bjam twice on the command line
<blush> Didn't I say I don't like having to type commands? <sheepish grin>
[etc]
Just follow the directions. They could be more clearly written, but you haven't even come close to typing equivalent commands to the ones listed on the Getting Started page.
Maybe I'm really just being dumb here. But I believe that there are many like me. (And not only on Windows. You should see a Mac guy here looking over my shoulder when I actually /type/ commands!)
Admittedly there should be example command lines for vc-7_1 etc and not just gcc.
IMO a straight bjam "-sTOOLS=<tools_name>" install with exact hinting at where to find "tools_name" would do. Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
On Wed, May 25, 2005 at 05:39:19PM +0200, Hendrik Schober wrote:
Admittedly there should be example command lines for vc-7_1 etc and not just gcc.
IMO a straight bjam "-sTOOLS=<tools_name>" install with exact hinting at where to find "tools_name" would do.
Then send a patch against the docs, won't take long, and might get accepted. jon -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
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
On 5/25/05, David Abrahams <dave@boost-consulting.com> wrote:
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?
Perhaps a new section in Getting Started, called something like "Quick Start for the Impatient": This is for the impatient developer who just wants to get up and running with any or all of Boost, but doesn't have the time or desire to learn the intricacies of the <link:Boost.Build> system. If you have one of the compilers mentioned below, you can build and install Boost by: * Microsoft Visual Studio .NET 2003 on Windows 2000 or XP (95/98?) ** Start Menu > Run > cmd ** bjam -sTOOLS=vc-7_1 ** Did you get an the error like <code>'bjam' is not recognized as an internal or external command, operable program or batch file</code>? Right click this <link:bjam.exe> and select Save As... c:\windows\bjam.exe (or c:\winnt\bjam.exe). Repeat the previous step. * Microsoft Visual Studio .NET 2005 Beta 2 on Windows 2000 or XP (95/98?) ** Same steps as for VS.NET 2003, but type <code>bjam -sTOOLS=vc-8_0 install</code> instead. * GNU gcc/g++ 3.3 (2.95? 3.2?) or later on just about any UNIX-like OS under the sun: ** Start a shell ** Download Boost from <link:tar.gz file>. ** Extract it by typing e.g. <code>tar xfz boost-<version>.tar.gz</code> ** chdir boost_<version> ** bjam -sTOOLS=gcc install [discuss --prefix?] ** Did you get an error like <code>bjam: command not found</code>? Type <code>chdir tools/build/jam_src && ./build.sh gcc</code>. Copy the resulting bjam executable from bin.<something> to ~ (e.g. <code>cp bin.<tab>/bjam ~</code>). Repeat the previous step, but begin with <code>~/bjam</code> instead of <code>bjam</code> [Others] -- Caleb Epstein caleb dot epstein at gmail dot com
On 5/26/05, Caleb Epstein <caleb.epstein@gmail.com> wrote:
* Microsoft Visual Studio .NET 2003 on Windows 2000 or XP (95/98?)
I missed this: ** Download Boost from here <link:Windows self-extracter>. Extract the files in C:\ [self extracter will create a boost_<version> subdir]
** Start Menu > Run > cmd
** Type <code>chdir c:\boost_<version></code>
** bjam -sTOOLS=vc-7_1
etc... -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein <caleb.epstein@gmail.com> writes:
On 5/25/05, David Abrahams <dave@boost-consulting.com> wrote:
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?
Perhaps a new section in Getting Started, called something like "Quick Start for the Impatient":
This is for the impatient developer who just wants to get up and running with any or all of Boost, but doesn't have the time or desire to learn the intricacies of the <link:Boost.Build> system. If you have one of the compilers mentioned below, you can build and install Boost by:
* Microsoft Visual Studio .NET 2003 on Windows 2000 or XP (95/98?)
** Start Menu > Run > cmd ** bjam -sTOOLS=vc-7_1 ** Did you get an the error like <code>'bjam' is not recognized as an internal or external command, operable program or batch file</code>? Right click this <link:bjam.exe> and select Save As... c:\windows\bjam.exe (or c:\winnt\bjam.exe). Repeat the previous step.
* Microsoft Visual Studio .NET 2005 Beta 2 on Windows 2000 or XP (95/98?)
** Same steps as for VS.NET 2003, but type <code>bjam -sTOOLS=vc-8_0 install</code> instead.
* GNU gcc/g++ 3.3 (2.95? 3.2?) or later on just about any UNIX-like OS under the sun:
** Start a shell ** Download Boost from <link:tar.gz file>. ** Extract it by typing e.g. <code>tar xfz boost-<version>.tar.gz</code> ** chdir boost_<version> ** bjam -sTOOLS=gcc install [discuss --prefix?] ** Did you get an error like <code>bjam: command not found</code>? Type <code>chdir tools/build/jam_src && ./build.sh gcc</code>. Copy the resulting bjam executable from bin.<something> to ~ (e.g. <code>cp bin.<tab>/bjam ~</code>). Repeat the previous step, but begin with <code>~/bjam</code> instead of <code>bjam</code>
You seriously want an example like that for every one of 51 toolsets? I don't think that's very reasonable unless we put that on the individual description page for each one. And I doubt anyone that didn't find his tools in the first three would page through the rest looking for what he needed. But maybe I'm too pessimistic. Would you like CVS access so you can try editing the site and we can see how it looks? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 5/26/05, David Abrahams <dave@boost-consulting.com> wrote:
You seriously want an example like that for every one of 51 toolsets?
Not hardly, no. Just the ones that are the most popular (probably only those three). Anyone on a different platform/toolchain will have to take a little time and RTFM. Please don't shoot the messenger. You asked for some examples, so I took the time and wrote them out in what I think is a very complete form. There's already a page on the Wiki called InstallingBoost, and perhaps it could be buffed up a bit (it offers the IMHO singularly bad advice of copying all the Boost headers and libs into the MSVC install dir) and linked to or included in-line in the Getting Started page. I already have CVS access, so I could make changes as appropriate. I'm leaving town this afternoon for the holiday weekend, so I don't know that I can get anything committed before Tuesday. Here's the Wiki page: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?InstallingBoo... Someone else suggested a web form could be used to generate the bjam command line from user input (e.g. pick your platform, compiler, desired configuration from pull-down menus). I like that idea lot. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein <caleb.epstein@gmail.com> writes:
On 5/26/05, David Abrahams <dave@boost-consulting.com> wrote:
You seriously want an example like that for every one of 51 toolsets?
Not hardly, no. Just the ones that are the most popular (probably only those three). Anyone on a different platform/toolchain will have to take a little time and RTFM.
Sounds fine, then. You just said "vc-7_1, etc." so how could I know.
Please don't shoot the messenger.
This ain't shootin', partner. When I'm shootin', you'll know it from the blood on your shirt.
You asked for some examples, so I took the time and wrote them out in what I think is a very complete form.
Very nice.
There's already a page on the Wiki called InstallingBoost, and perhaps it could be buffed up a bit (it offers the IMHO singularly bad advice of copying all the Boost headers and libs into the MSVC install dir) and linked to or included in-line in the Getting Started page.
I don't think the Wiki is the right place for the easy-to-use getting started guide. It should be a very stable part of the main Boost website.
I already have CVS access, so I could make changes as appropriate.
Go for it, but please keep the important information within the main Boost website. Note that any changes you make will be reflected at http://www.boost-consulting.com/boost within an hour or 2.
I'm leaving town this afternoon for the holiday weekend, so I don't know that I can get anything committed before Tuesday.
That's soon enough for me.
Here's the Wiki page:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?InstallingBoo...
Someone else suggested a web form could be used to generate the bjam command line from user input (e.g. pick your platform, compiler, desired configuration from pull-down menus). I like that idea lot.
Need volunteers. :^) -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Please don't shoot the messenger.
This ain't shootin', partner. When I'm shootin', you'll know it from the blood on your shirt.
What I mean to say, in case it isn't obvious, is that I appreciate your input and have no intention to attack you. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Caleb Epstein wrote:
Here's the Wiki page:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?InstallingBoo...
Someone else suggested a web form could be used to generate the bjam command line from user input (e.g. pick your platform, compiler, desired configuration from pull-down menus). I like that idea lot.
Why don't we just put vc-2003-default-build.bat? @prompt $g cd tools\build\jam_src call build.bat vc7 cd ..\..\.. tools\build\jam_src\bin.ntx86\bjam.exe bjam -sTOOLS=vc-7_1 install This will work for the vast majority of configurations. And users won't have to use shell at all... Just double-click from explorer or other file manager they use.. Andrey
On Wed, May 25, 2005 at 07:18:46PM -0400, David Abrahams wrote:
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?
Maybe the example should feature VC, since the VC users are the ones likely to be least familiar and least comfortable with a command line tool and figuring out the right options. Unix users are used to scouring man pages to determine the right set of cryptic flags and switches, so tailor it to the users who need the most hand-holding with the command-line process. jon
"Jonathan Wakely" <cow@compsoc.man.ac.uk> wrote in message news:20050526103904.GA87354@compsoc.man.ac.uk...
On Wed, May 25, 2005 at 07:18:46PM -0400, David Abrahams wrote:
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?
Maybe the example should feature VC, since the VC users are the ones likely to be least familiar and least comfortable with a command line tool and figuring out the right options.
Unix users are used to scouring man pages to determine the right set of cryptic flags and switches, so tailor it to the users who need the most hand-holding with the command-line process.
This is absolutely one of those ideas that after you hear it, you think, "well that was obvious". :) It provides the biggest bang for the samllest change. I think that if the current example were as you suggest, this whole topic probably would not have come up. Issuing: bjam "-sTOOLS=vc-7_1" install would probably do what the majority of first time users would intuit. I would probably have windows explorer open and have gotten visual feedback on where the directories were placed. If I didn't like the default location, I would just move the directories to where I wanted them. Now my only concerns would be the ease of getting a bjam.exe available and the inconsistency in naming for the VC targets: msvc // VC6.5 can we add vc6_5? vc7 // VC7 would vc7_0 be better? vc-7_1 // VC7.1 why the dash? why not vc7_1? Jeff Flinn
Attached patch implements the idea I proposed below, in case it's wanted. jon On Thu, May 26, 2005 at 08:48:39AM -0400, Jeff Flinn wrote:
"Jonathan Wakely" <cow@compsoc.man.ac.uk> wrote in message news:20050526103904.GA87354@compsoc.man.ac.uk...
On Wed, May 25, 2005 at 07:18:46PM -0400, David Abrahams wrote:
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?
Maybe the example should feature VC, since the VC users are the ones likely to be least familiar and least comfortable with a command line tool and figuring out the right options.
Unix users are used to scouring man pages to determine the right set of cryptic flags and switches, so tailor it to the users who need the most hand-holding with the command-line process.
This is absolutely one of those ideas that after you hear it, you think, "well that was obvious". :) It provides the biggest bang for the samllest change.
I think that if the current example were as you suggest, this whole topic probably would not have come up. Issuing:
bjam "-sTOOLS=vc-7_1" install
would probably do what the majority of first time users would intuit. I would probably have windows explorer open and have gotten visual feedback on where the directories were placed. If I didn't like the default location, I would just move the directories to where I wanted them.
Now my only concerns would be the ease of getting a bjam.exe available and the inconsistency in naming for the VC targets:
msvc // VC6.5 can we add vc6_5? vc7 // VC7 would vc7_0 be better? vc-7_1 // VC7.1 why the dash? why not vc7_1?
Jeff Flinn
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- "Surrealism aims at the total transformation of the mind and all that resembles it" - Breton
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
Attached patch implements the idea I proposed below, in case it's wanted.
Now that I look at it, I guess its effectiveness will be vastly reduced if we don't implement naming consistency for vc6 and 7, right?
Index: more/getting_started.html =================================================================== RCS file: /cvsroot/boost/boost/more/getting_started.html,v retrieving revision 1.25 diff -u -p -b -B -r1.25 getting_started.html --- more/getting_started.html 6 May 2005 13:17:37 -0000 1.25 +++ more/getting_started.html 26 May 2005 13:36:59 -0000 @@ -387,13 +387,13 @@ <tr vAlign="top" align="left"> <td vAlign="top" align="center" width="40" bgColor="#ffff66"><font size="6"><b><a id="step5" name="step5"></a>5</b></font></td> <td>Invoke the build system, specifying the <A href="#Tools">toolset</A>(s) you - wish to use, to build and install. For example for GNU/GCC. <blockquote> - <p><code>bjam "-sTOOLS=gcc" install</code></p> + wish to use, to build and install. For example for VC++ 7.1: <blockquote> + <p><code>bjam "-sTOOLS=vc-7_1" install</code></p> </blockquote> <p>Or if you are interested only in the built libraries you can have them built and collected to a common directory without installation.</p> <blockquote> - <p><code>bjam "-sTOOLS=gcc" stage</code></p> + <p><code>bjam "-sTOOLS=vc-7_1" stage</code></p> </blockquote> </td> </tr> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
Attached patch implements the idea I proposed below, in case it's wanted.
Now that I look at it, I guess its effectiveness will be vastly reduced if we don't implement naming consistency for vc6 and 7, right?
Yes, definitely. And how about extending this (or coming up with another scheme) so that it equally applies to all tool sets? Because my next question would be: How do I build for GCC 3.3.3 and 3.4.X? And does "cw" really apply to CW6, 7, 8, and 9???
[...]
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
On Fri, May 27, 2005 at 10:51:32AM +0200, Hendrik Schober wrote:
David Abrahams <dave@boost-consulting.com> wrote:
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
Attached patch implements the idea I proposed below, in case it's wanted.
Now that I look at it, I guess its effectiveness will be vastly reduced if we don't implement naming consistency for vc6 and 7, right?
Yes, definitely. And how about extending this (or coming up with another scheme) so that it equally applies to all tool sets? Because my next question would be: How do I build for GCC 3.3.3 and 3.4.X?
You'd click on "gcc" in the toolset table (you managed to click the "vc7" toolset and pick a variable there, surely you can do it for GCC :) That shows the valid variables for the gcc toolset, among them is GCC_ROOT_DIRECTORY. Set that to the right place for each GCC installation you want to use. They don't need different toolsets because they work the same and take the same options so the same JamFiles work for any version of GCC. I use something like the following for each GCC I build for: GCC_ROOT_DIRECTORY = /foo/bar/gcc/4.x ; and because I have a 64-bit machine: GCC_STDLIB_DIRECTORY = /foo/bar/gcc/4.x/lib64 ;
And does "cw" really apply to CW6, 7, 8, and 9???
Probably, I don't know for sure. As with GCC the same JamFiles probably work for all versions. jon
Jonathan Wakely <cow@compsoc.man.ac.uk> wrote:
[...] And how about extending this (or coming up with another scheme) so that it equally applies to all tool sets? Because my next question would be: How do I build for GCC 3.3.3 and 3.4.X?
You'd click on "gcc" in the toolset table (you managed to click the "vc7" toolset and pick a variable there, surely you can do it for GCC :)
Ouch, wasn't this wrong when I did it the first time? :) But now I see -- I need to specifiy the -- what's it called? -- ^W^W^W^W^W configure the tool first. Mhmm. Thinking about it -- that's quite different from VC, isn't it? Why?
[...] jon
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
On Fri, May 27, 2005 at 12:49:11PM +0200, Hendrik Schober wrote:
Jonathan Wakely <cow@compsoc.man.ac.uk> wrote:
[...] And how about extending this (or coming up with another scheme) so that it equally applies to all tool sets? Because my next question would be: How do I build for GCC 3.3.3 and 3.4.X?
You'd click on "gcc" in the toolset table (you managed to click the "vc7" toolset and pick a variable there, surely you can do it for GCC :)
Ouch, wasn't this wrong when I did it the first time? :)
Yes, it was wrong when you were trying to find the value for TOOLS, it is right if you're trying to find some toolset-specific variable. It's wrong to use a variable name as a toolset name. It's right to use a variable name as a variable name. Got it? Look: bjam -sTOOLS=gcc -sGCC_ROOT_DIRECTORY=/home/redi/gcc/4.x
But now I see -- I need to specifiy the -- what's it called? -- ^W^W^W^W^W configure the tool first.
Mhmm. Thinking about it -- that's quite different from VC, isn't it? Why?
No, not really: bjam -sTOOLS=vc7_1 -sVC71_ROOT=... Good luck, I'm thoroughly bored with this thread now. jon -- "This Statement is False" (Courtesy of POEE)
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
Attached patch implements the idea I proposed below, in case it's wanted.
Now that I look at it, I guess its effectiveness will be vastly reduced if we don't implement naming consistency for vc6 and 7, right?
Yes, definitely. And how about extending this (or coming up with another scheme) so that it equally applies to all tool sets? Because my next question would be: How do I build for GCC 3.3.3 and 3.4.X? And does "cw" really apply to CW6, 7, 8, and 9???
Just a question of how much effort we want to invest in a dying Boost.Build v1 -- all of this is better in BBv2 -- and, of course, a volunteer to do the work. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
[...] Just a question of how much effort we want to invest in a dying Boost.Build v1 -- all of this is better in BBv2 [...]
I see. Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
David Abrahams <dave@boost-consulting.com> writes:
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
Attached patch implements the idea I proposed below, in case it's wanted.
Now that I look at it, I guess its effectiveness will be vastly reduced if we don't implement naming consistency for vc6 and 7, right?
Yes, definitely. And how about extending this (or coming up with another scheme) so that it equally applies to all tool sets? Because my next question would be: How do I build for GCC 3.3.3 and 3.4.X?
Jonathan answered that.
And does "cw" really apply to CW6, 7, 8, and 9???
No, we never supported cw6, but yes to the rest.
Just a question of how much effort we want to invest in a dying Boost.Build v1 -- all of this is better in BBv2 -- and, of course, a volunteer to do the work.
By the way, anyone who wants to make things better can do this job. It doesn't require any special expertise at all. Just a matter of renaming some files, dropping in some other boilerplate for backward compatibility, and updating the documentation. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
David Abrahams <dave@boost-consulting.com> writes:
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
Attached patch implements the idea I proposed below, in case it's wanted.
Now that I look at it, I guess its effectiveness will be vastly reduced if we don't implement naming consistency for vc6 and 7, right?
Yes, definitely. And how about extending this (or coming up with another scheme) so that it equally applies to all tool sets? Because my next question would be: How do I build for GCC 3.3.3 and 3.4.X?
Jonathan answered that.
And does "cw" really apply to CW6, 7, 8, and 9???
No, we never supported cw6, but yes to the rest.
Just a question of how much effort we want to invest in a dying Boost.Build v1 -- all of this is better in BBv2 -- and, of course, a volunteer to do the work.
By the way, anyone who wants to make things better can do this job. It doesn't require any special expertise at all. Just a matter of renaming some files, dropping in some other boilerplate for backward compatibility, and updating the documentation.
It would take less time than many of us have spent posting in this thread. I will be happy to provide guidance (hint, hint). -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Just a question of how much effort we want to invest in a dying Boost.Build v1 -- all of this is better in BBv2 -- and, of course, a volunteer to do the work.
From the documentation it looks like BBv2 is an experimental thing. I even didn't know that it supports vc versions other than vc6 until I looked in toolset Jam file. If it is stable and does support vc 7.0, 7.1 and 8.0, why everybody is talking about v1 here? Andrey
Andrey Melnikov <melnikov@simplexsoft.com> writes:
David Abrahams wrote:
Just a question of how much effort we want to invest in a dying Boost.Build v1 -- all of this is better in BBv2 -- and, of course, a volunteer to do the work.
From the documentation it looks like BBv2 is an experimental thing.
It's not experimental, but it is "under development"
I even didn't know that it supports vc versions other than vc6 until I looked in toolset Jam file.
If it is stable and does support vc 7.0, 7.1 and 8.0, why everybody is talking about v1 here?
Because v1 is still the official build system of Boost. We haven't quite been able to replace it with v2 yet. We aim to do that immediately after Boost 1.33 is released. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hendrik Schober wrote:
Yes, definitely. And how about extending this (or coming up with another scheme) so that it equally applies to all tool sets? Because my next question would be: How do I build for GCC 3.3.3 and 3.4.X? And does "cw" really apply to CW6, 7, 8, and 9???
I agree. For Borland, we could have bcc5_5 - C++Builder 5/Free command-line tools bcc5_6 - C++Builder 6 bcc5_7 - Kylix (don't know which version) Cheers Russell
On 5/26/05, Jonathan Wakely <cow@compsoc.man.ac.uk> wrote:
Attached patch implements the idea I proposed below, in case it's wanted.
I think that you should call the toolset "Visual Studio .NET 2003" and not "VC++ 7.1". Other than that this looks great. -- Caleb Epstein caleb dot epstein at gmail dot com
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
"Jonathan Wakely" <cow@compsoc.man.ac.uk> wrote in message news:20050526103904.GA87354@compsoc.man.ac.uk...
On Wed, May 25, 2005 at 07:18:46PM -0400, David Abrahams wrote:
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?
Maybe the example should feature VC, since the VC users are the ones likely to be least familiar and least comfortable with a command line tool and figuring out the right options.
Unix users are used to scouring man pages to determine the right set of cryptic flags and switches, so tailor it to the users who need the most hand-holding with the command-line process.
This is absolutely one of those ideas that after you hear it, you think, "well that was obvious". :) It provides the biggest bang for the samllest change.
I think that if the current example were as you suggest, this whole topic probably would not have come up. Issuing:
bjam "-sTOOLS=vc-7_1" install
would probably do what the majority of first time users would intuit.
Unless they did what Schobi did (twice): type ..\bjam.exe and then paste the entire command line. But if a change like that will make a difference, send me your SF user name and I'll give you CVS access, so you can fix it.
I would probably have windows explorer open and have gotten visual feedback on where the directories were placed. If I didn't like the default location, I would just move the directories to where I wanted them.
Now my only concerns would be the ease of getting a bjam.exe available
We've always had a binary download for windows available. What more do you need?
and the inconsistency in naming for the VC targets:
msvc // VC6.5 can we add vc6_5? vc7 // VC7 would vc7_0 be better? vc-7_1 // VC7.1 why the dash? why not vc7_1?
The dash is there for dumb reasons: we call the toolset files <toolsetname>-tools.jam and for the purposes of building a Boost distro on CD we can't have filenames with multiple '.' characters in them, so we changed '.' to '_' in the names of things like vc-7.1-tools.jam. But we should have changed BBv1 to allow users to type a '.' on the command-line and translate it internally when we made that change; it would be pretty easy. As for naming consistency, yes, it would probably be better. BBv2 fixes all of these problems, and we've been reluctant to make trivial improvements in BBv1 because it's been so long anticipated that it would be retired. Now it looks like it won't be retired until just after 1.33, so it's a toss-up whether we should do anything about it. I'm willing to go either way. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
and the inconsistency in naming for the VC targets:
msvc // VC6.5 can we add vc6_5? vc7 // VC7 would vc7_0 be better? vc-7_1 // VC7.1 why the dash? why not vc7_1?
The dash is there for dumb reasons: we call the toolset files
<toolsetname>-tools.jam
and for the purposes of building a Boost distro on CD we can't have filenames with multiple '.' characters in them, so we changed '.' to '_' in the names of things like vc-7.1-tools.jam. But we should have changed BBv1 to allow users to type a '.' on the command-line and translate it internally when we made that change; it would be pretty easy. As for naming consistency, yes, it would probably be better.
BBv2 fixes all of these problems, and we've been reluctant to make trivial improvements in BBv1 because it's been so long anticipated that it would be retired. Now it looks like it won't be retired until just after 1.33, so it's a toss-up whether we should do anything about it. I'm willing to go either way.
It's easy enough to add vc-7_0-tools.jam, and vc-6_5-tools.jam that just refer to the current files. So I think we can go ahead and do it. The "." to "_" translation might be harder as there a people who have their own toolsets with x.x in them. We'll have to think about that one. -- -- 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
Rene Rivera <grafik.list@redshift-software.com> writes:
David Abrahams wrote:
and the inconsistency in naming for the VC targets:
msvc // VC6.5 can we add vc6_5? vc7 // VC7 would vc7_0 be better? vc-7_1 // VC7.1 why the dash? why not vc7_1? The dash is there for dumb reasons: we call the toolset files <toolsetname>-tools.jam and for the purposes of building a Boost distro on CD we can't have filenames with multiple '.' characters in them, so we changed '.' to '_' in the names of things like vc-7.1-tools.jam. But we should have changed BBv1 to allow users to type a '.' on the command-line and translate it internally when we made that change; it would be pretty easy. As for naming consistency, yes, it would probably be better. BBv2 fixes all of these problems, and we've been reluctant to make trivial improvements in BBv1 because it's been so long anticipated that it would be retired. Now it looks like it won't be retired until just after 1.33, so it's a toss-up whether we should do anything about it. I'm willing to go either way.
It's easy enough to add vc-7_0-tools.jam, and vc-6_5-tools.jam that just refer to the current files. So I think we can go ahead and do it.
The "." to "_" translation might be harder as there a people who have their own toolsets with x.x in them. We'll have to think about that one.
That's easy enough to do with GLOB. You just look to see if the toolset exists verbatim, and if not, make the transformation. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Rene Rivera" <grafik.list@redshift-software.com> wrote in message news:4295E416.6030803@redshift-software.com...
David Abrahams wrote:
and the inconsistency in naming for the VC targets:
msvc // VC6.5 can we add vc6_5? vc7 // VC7 would vc7_0 be better? vc-7_1 // VC7.1 why the dash? why not vc7_1?
The dash is there for dumb reasons: we call the toolset files <toolsetname>-tools.jam
and for the purposes of building a Boost distro on CD we can't have filenames with multiple '.' characters in them, so we changed '.' to '_' in the names of things like vc-7.1-tools.jam. But we should have changed BBv1 to allow users to type a '.' on the command-line and translate it internally when we made that change; it would be pretty easy. As for naming consistency, yes, it would probably be better.
BBv2 fixes all of these problems, and we've been reluctant to make trivial improvements in BBv1 because it's been so long anticipated that it would be retired. Now it looks like it won't be retired until just after 1.33, so it's a toss-up whether we should do anything about it. I'm willing to go either way.
It's easy enough to add vc-7_0-tools.jam, and vc-6_5-tools.jam that just refer to the current files. So I think we can go ahead and do it.
The "." to "_" translation might be harder as there a people who have their own toolsets with x.x in them. We'll have to think about that one.
It just occurred to me that as an infrequent command line user, that the dashes in names are intimidating because I have always thought that '-' is a special character for introducing a parameter. So that makes 'vc-7_1' look more complex than it may really be. Do most users ever see(or need be concerned with) what these parameters eventually expand to? Jeff Flinn
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
"Rene Rivera" <grafik.list@redshift-software.com> wrote in message news:4295E416.6030803@redshift-software.com...
David Abrahams wrote:
and the inconsistency in naming for the VC targets:
msvc // VC6.5 can we add vc6_5? vc7 // VC7 would vc7_0 be better? vc-7_1 // VC7.1 why the dash? why not vc7_1?
The dash is there for dumb reasons: we call the toolset files <toolsetname>-tools.jam
and for the purposes of building a Boost distro on CD we can't have filenames with multiple '.' characters in them, so we changed '.' to '_' in the names of things like vc-7.1-tools.jam. But we should have changed BBv1 to allow users to type a '.' on the command-line and translate it internally when we made that change; it would be pretty easy. As for naming consistency, yes, it would probably be better.
BBv2 fixes all of these problems, and we've been reluctant to make trivial improvements in BBv1 because it's been so long anticipated that it would be retired. Now it looks like it won't be retired until just after 1.33, so it's a toss-up whether we should do anything about it. I'm willing to go either way.
It's easy enough to add vc-7_0-tools.jam, and vc-6_5-tools.jam that just refer to the current files. So I think we can go ahead and do it.
The "." to "_" translation might be harder as there a people who have their own toolsets with x.x in them. We'll have to think about that one.
It just occurred to me that as an infrequent command line user, that the dashes in names are intimidating because I have always thought that '-' is a special character for introducing a parameter. So that makes 'vc-7_1' look more complex than it may really be.
Well, I'm not willing to forego dashes in file/command names. Underscores take an extra shift key ;-)
Do most users ever see(or need be concerned with) what these parameters eventually expand to?
I don't understand the question. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uekbtq4f8.fsf@boost-consulting.com...
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
"Rene Rivera" <grafik.list@redshift-software.com> wrote in message news:4295E416.6030803@redshift-software.com...
David Abrahams wrote:
and the inconsistency in naming for the VC targets:
msvc // VC6.5 can we add vc6_5? vc7 // VC7 would vc7_0 be better? vc-7_1 // VC7.1 why the dash? why not vc7_1?
The dash is there for dumb reasons: we call the toolset files <toolsetname>-tools.jam
...
Do most users ever see(or need be concerned with) what these parameters eventually expand to?
I don't understand the question.
The previous response implied that the "-sTOOLS=vc-7_1" was used to generate file names like "vc-7_1-tools.jam". This led me to believe that the dashes and dots are currently required to ease the generation of such filenames. I've never needed to know what was going on under the hood of bjam/build in the past. So if more user friendly names, I'd think that I wouldn't ever notice that "sTOOLS=vc7_1" generated/used file(s) named "vc-7_1-tools.jam". So couldn't there be more separation between the presentation and representation of the build system? In other words are the following doable? bjam "-sTOOLS=vc6_5" install bjam "-sTOOLS=vc7_0" install bjam "-sTOOLS=vc7_1" install Thanks, Jeff
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uekbtq4f8.fsf@boost-consulting.com...
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
"Rene Rivera" <grafik.list@redshift-software.com> wrote in message news:4295E416.6030803@redshift-software.com...
David Abrahams wrote:
and the inconsistency in naming for the VC targets:
msvc // VC6.5 can we add vc6_5? vc7 // VC7 would vc7_0 be better? vc-7_1 // VC7.1 why the dash? why not vc7_1?
The dash is there for dumb reasons: we call the toolset files <toolsetname>-tools.jam
...
Do most users ever see(or need be concerned with) what these parameters eventually expand to?
I don't understand the question.
The previous response implied that the "-sTOOLS=vc-7_1" was used to generate file names like "vc-7_1-tools.jam". This led me to believe that the dashes and dots are currently required to ease the generation of such filenames.
Well, yeah. The elements of the TOOLS variable get "-tools.jam" appended and that's treated as a toolset file name.
I've never needed to know what was going on under the hood of bjam/build in the past. So if more user friendly names, I'd think that I wouldn't ever notice that "sTOOLS=vc7_1" generated/used file(s) named "vc-7_1-tools.jam". So couldn't there be more separation between the presentation and representation of the build system?
That's just hard to program and maintain.
In other words are the following doable?
bjam "-sTOOLS=vc6_5" install bjam "-sTOOLS=vc7_0" install bjam "-sTOOLS=vc7_1" install
Sure, but the easy way is just to rename the toolset files. But seriously, you really are comfortable with the underscore? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:upsvdiqoi.fsf@boost-consulting.com... ...
In other words are the following doable?
bjam "-sTOOLS=vc6_5" install bjam "-sTOOLS=vc7_0" install bjam "-sTOOLS=vc7_1" install
Sure, but the easy way is just to rename the toolset files. But seriously, you really are comfortable with the underscore?
Yes, as an underscore is commonly seen in identifiers throughout boost, stl and C++ for that matter. I (perhaps incorrectly?) view vc6_5, vc7_0, vc7_1 as identifiers in this context as well. Pressing a few extra shift keys once every 4-6 months when installing a new version of boost seems like little overhead to me. ;-) Jeff
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:upsvdiqoi.fsf@boost-consulting.com...
...
In other words are the following doable?
bjam "-sTOOLS=vc6_5" install bjam "-sTOOLS=vc7_0" install bjam "-sTOOLS=vc7_1" install
Sure, but the easy way is just to rename the toolset files. But seriously, you really are comfortable with the underscore?
Yes, as an underscore is commonly seen in identifiers throughout boost, stl and C++ for that matter. I (perhaps incorrectly?) view vc6_5, vc7_0, vc7_1 as identifiers in this context as well. Pressing a few extra shift keys once every 4-6 months when installing a new version of boost seems like little overhead to me. ;-)
It just seems like a silly opportunity for confusion to use underscores when we can easily use dots. Nobody says "I'm using Visual C++ 6_5." -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uu0koacaj.fsf@boost-consulting.com...
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
Sure, but the easy way is just to rename the toolset files. But seriously, you really are comfortable with the underscore?
Yes, as an underscore is commonly seen in identifiers throughout boost, stl and C++ for that matter. I (perhaps incorrectly?) view vc6_5, vc7_0, vc7_1 as identifiers in this context as well. Pressing a few extra shift keys once every 4-6 months when installing a new version of boost seems like little overhead to me. ;-)
It just seems like a silly opportunity for confusion to use underscores when we can easily use dots. Nobody says "I'm using Visual C++ 6_5."
Well, I can be happy with vc6.5, vc7.0 and vc7.1 too. My main dislike is the use of '-' in the name. Jeff
At 09:07 2005-05-26, Jeff Flinn wrote:
It just occurred to me that as an infrequent command line user, that the dashes in names are intimidating because I have always thought that '-' is a special character for introducing a parameter. So that makes 'vc-7_1' look more complex than it may really be.
'-' isn't used in windows to introduce options, '/' is. Also, if they're not preceeded by a space ' ' then they aren't special.
Do most users ever see(or need be concerned with) what these parameters eventually expand to?
Jeff Flinn
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uekbuw08z.fsf@boost-consulting.com...
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
...
I think that if the current example were as you suggest, this whole topic probably would not have come up. Issuing:
bjam "-sTOOLS=vc-7_1" install
would probably do what the majority of first time users would intuit.
Unless they did what Schobi did (twice): type ..\bjam.exe and then paste the entire command line.
But if a change like that will make a difference, send me your SF user name and I'll give you CVS access, so you can fix it.
Ok, I'm a real neophyte here though. I assume somehow that I need to get a SF user name. Any hints on doing that? Does this mean I subscribe to sourceforge?
Now my only concerns would be the ease of getting a bjam.exe available
We've always had a binary download for windows available. What more do you need?
Currently "I" don't need anything more. ;) I'll have to take a look at that again. I downloaded bjam.exe at least a couple of years ago, and copied it to my C:\boost directory. Then I copy it to each boost version directory when I download/unzip a new version of boost. I remember way back in 2000, that I was under the impression that I had to get the bjam project and build it to get a bjam.exe. Can one say that those users that download a .zip(or self extracting .exe) of boost are on windows? Couldn't a windows bjam.exe be added to the version's root directory? Then you just do a cd to C:\boost\boost_1_32_0 and run "bjam -sTOOLS=vc-7_1 install". Or possibly add a setup.bat file that you can double-click on from windows explorer?
and the inconsistency in naming for the VC targets:
msvc // VC6.5 can we add vc6_5? vc7 // VC7 would vc7_0 be better? vc-7_1 // VC7.1 why the dash? why not vc7_1?
The dash is there for dumb reasons: we call the toolset files
<toolsetname>-tools.jam
and for the purposes of building a Boost distro on CD we can't have filenames with multiple '.' characters in them, so we changed '.' to '_' in the names of things like vc-7.1-tools.jam. But we should have changed BBv1 to allow users to type a '.' on the command-line and translate it internally when we made that change; it would be pretty easy. As for naming consistency, yes, it would probably be better.
I see no problem with 7_1 rather than 7.1. I think having '.','-' and '_' in a single command line parameter is is more confusing than say 'vc7_1'.
BBv2 fixes all of these problems, and we've been reluctant to make trivial improvements in BBv1 because it's been so long anticipated that it would be retired. Now it looks like it won't be retired until just after 1.33, so it's a toss-up whether we should do anything about it. I'm willing to go either way.
Of course that would bring up the (rhetorical)question of how long before a 1.34 release? Thanks, Jeff Flinn
David Abrahams <dave@boost-consulting.com> wrote:
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes: [...]
I think that if the current example were as you suggest, this whole topic probably would not have come up. Issuing:
bjam "-sTOOLS=vc-7_1" install
would probably do what the majority of first time users would intuit.
Unless they did what Schobi did (twice): type ..\bjam.exe and then paste the entire command line.
Yes, but there's very little you can do against such dumbness. :)
[...]
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
Hendrik Schober wrote:
David Abrahams <dave@boost-consulting.com> wrote:
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
Unless they did what Schobi did (twice): type ..\bjam.exe and then paste the entire command line.
Yes, but there's very little you can do against such dumbness. :)
Unless you'll eliminate manual typing from build process completely :) Andrei
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
On Wed, May 25, 2005 at 07:18:46PM -0400, David Abrahams wrote:
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?
Maybe the example should feature VC, since the VC users are the ones likely to be least familiar and least comfortable with a command line tool and figuring out the right options.
I agree that will help a very large proportion of the users.
Unix users are used to scouring man pages to determine the right set of cryptic flags and switches, so tailor it to the users who need the most hand-holding with the command-line process.
Not a bad idea. Patches are welcome, BTW. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Hendrik Schober" <SpamTrap@gmx.de> writes:
Caleb Epstein <caleb.epstein@gmail.com> wrote:
[...] I really think the Getting Started guide is more than adequate, and is concise and easy to follow. There are gigantic yellow numbers next to the important steps. [...] really how much more hand-holding does one need?
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? Just to be absolutely picky about it, the guide does not tell you to type .\bjam.exe ...stuff... but bjam ...stuff... And that might be why you repeated "bjam" on the command-line.
After quite a pause ("what's it doing now?")
Good point; we should have it say something.
it spit out a lengthy messagethat that I have an incorrect configuration. It couldn't find Python. Mhmm. Do I need this? Will it even work without Python? (I know it will. But not from the guide.)
Well the message you *actually* get is: skipping Boost.Python library build due to _missing_ _or_ _incorrect_ configuration followed by some other stuff. So if that is insufficient to make it clear that the build will will work even without Python, what do we need to do in order to make it clear?
Next thing it emits is don't know how to make bjam Yikes! What does that mean? It surely doesn't mean it wants to compile/link bjam as I am /running/ it already, right? Scary.
No, it means that you typed an extra "bjam" on your command-line. I really don't know what we could do to make it clearer that you're not supposed to do that.
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. But where did you get the idea that VC71_ROOT was a legal toolset name?
Now I am really really baffled. I mean, I pasted that line from the guide (except for replacing "gcc" with what I thought the guide says I need to replace it with).
If you misread the guide sufficiently badly, it's possible to produce arbitrarily bad outcomes. Of course, if you're misreading the guide it's the guide's fault. But how could we have made it clearer? It's hard for me to see how we led you to invent the command line you used.
Doesn't that thing even recognise its options? Finally, it advices ...patience... Oh good. So I'll wait. Further: ...found 4471 targets... ...updating 1123 targets... ...can't find 2 targets... Um, what are targets?
Standard build-system-eze for "element of the build dependency graph." These messages are inherited from jam; should we remove them?
Why does it only "update" a quarter of them?
The others are up-to-date.
Why wouldn't it find 2 of them? I read the guide again. Damn! I messed this up! I need to pass "vc", not "VC71_ROOT"! The guid is a bit terse in that area...
Where did you get the idea you needed to pass "vc"? This is not a criticism; we need to know how you were led into this so we can figure out how to fix it.
CTRL-C C:\Temp\Download\boost\boost_1_32_0>..\bjam.exe bjam "-sTOOLS=vc" stage Alas, same result. Excep that now it don't know how to make -sTOOLS=vc
It's that extra "bjam" again.
Huh? Well, it says I should be patient, so I just let it do whatever it does. There really are a few libs in "bin" at the end. And the thing says ...updated 1120 targets... Mhmm. Three missing. It might have even emitted an error message. No way I'm going to wade through 3-4k lines of messages to find those three.
Should the tool be silent while building unless it encounters an error? Perhaps a string of dots, just so you know there's progress?
Now I would need to link to this stuff. But where exactly do I need to point my linker at?
Really, is there something unclear about http://www.boost.org/more/getting_started.html#Build_Install ?? The default build and install attempts to build all available libraries and install to default locations the libraries and Boost header files. On Unix systems the default install location is "/usr/local", and on Windows systems the default is "C:\Boost". Within those directories libraries are installed to the "lib" subdirectory, and headers to an "include/boost-1_31" subdirectory, the version will reflect the distribution you are installing. I can't imagine how we could make this clearer. Can you help?
The guide has something on automatic linking on Windows, but I can't find where in the folder hierarchy this assumes I'm anchored.
I don't know what you mean by "anchored." I would assume that the dynamic libraries need to be in your PATH, and that's all. But I'm not an expert in this area.
Still long ways to go before I can start to work. Add to this that, as with all new stuff, I will still stumble more later while using this, that I would have to write a usage guide for my fellows if I want to use this (hey, some of them aren't as good reading English, they will never be able to follow this guide!), and that we need to figure this out for another handful of platforms -- and I start to think if it really is worth all the hassle.
I can understand that.
Conclusion: I have seen smoother installations on Windows,
Certainly. We should be providing an installer with pre-built binaries.
I have installed easier to build libs, and I have seen guides that weren't written for mere insiders.
Now wait a minute. Whatever it's failings, this guide was written specifically for non-insiders.
I'm no command-line afficinado, I can barely read makefiles, and I am used to having a GUI and online-help for every option. Call me dumb, but I am one of millions of potential boost users. We use boost since years ago, when I threw out all home-grown smart pointers and replaced them by boost's. So we /know/ boost is worth quite a lot of hassle and we even use one library that's not headers-only. (However, this one -- regex -- comes with a makefile and this we knew how to integrate into the build.) But if this was my first look at boost, I'd delete it right away. Seriously, on this platform are millions of C++ users that only heard very vague rumours of C++ being standardized -- if they heard about it at all. Those don't see much benefit it smart pointers, consider the MPL to be black art, and can't be bothered if it isn't really easy to use.
Yep, we need to do better. Can you help us understand what to change? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Hendrik Schober" <SpamTrap@gmx.de> writes:
Caleb Epstein <caleb.epstein@gmail.com> wrote:
[...] it spit out a lengthy messagethat that I have an incorrect configuration. It couldn't find Python. Mhmm. Do I need this? Will it even work without Python? (I know it will. But not from the guide.)
Well the message you *actually* get is:
skipping Boost.Python library build due to _missing_ _or_ _incorrect_ configuration
followed by some other stuff. So if that is insufficient to make it clear that the build will will work even without Python, what do we need to do in order to make it clear?
Perhaps the output should be something like the current linux kernel or kde's build systems output: ... Building boost_program_options ... [ok] Building boost_pyhton ... [skipped] Couldn't find an installation of Python, which is needed for this target. If you don't use Boost.Python you don't have to worry about this. Building boost_spirit ... [ok] ...
Should the tool be silent while building unless it encounters an error?
I think so. Perhaps provide a --verbose options which also states which commands get executed.
Perhaps a string of dots, just so you know there's progress?
I like "Building <target_name> ..." better.
Now I would need to link to this stuff. But where exactly do I need to point my linker at?
Really, is there something unclear about http://www.boost.org/more/getting_started.html#Build_Install ??
I can't imagine how we could make this clearer. Can you help?
Perhaps output something like: Installed Boost 1.33 into "C:\Boost". Headers are installed in "C:\Boost\include\boost-1_33" Libraries are installed in "C:\Boost\lib" add this to your PATH for automatic linking. at the end of the bjam run?
Conclusion: I have seen smoother installations on Windows,
Certainly. We should be providing an installer with pre-built binaries.
I have installed easier to build libs, and I have seen guides that weren't written for mere insiders.
Lucky you. ;) I have yet to find an binary install which realy works out of the box, under all circumstances, and a Guide which helps in the cases where the installer crashes, or doesn't do the right thing. I found the boost installation under windows quite easy, compared to some other libs I had to install, but that might be because i don't know Windows too well, and found installing libraries under Windows quite complicated in comparison with Linux. Just my ?0.02 Fabio
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.
Just to be absolutely picky about it, the guide does not tell you to type .\bjam.exe ...stuff...
but bjam ...stuff...
And that might be why you repeated "bjam" on the command-line.
Yep, because I copied the line from the docs. :) (Did I mention I don't like typing commands?)
After quite a pause ("what's it doing now?")
Good point; we should have it say something.
I supposed it checked some dependencies. I don't think this pause was very distracting to me. But a short note would do a lot for many people.
[...]
Mhmm. Do I need this? Will it even work without Python? (I know it will. But not from the guide.)
Well the message you *actually* get is:
skipping Boost.Python library build due to _missing_ _or_ _incorrect_ configuration
followed by some other stuff. So if that is insufficient to make it clear that the build will will work even without Python, what do we need to do in order to make it clear?
Suppose you never heard of boost until this fellow told you you should check it out. You download it. The "Getting Start(l)ed" guide says it needs to get built before you can use it. <sigh> It doesn't come with a project for your IDE. <breathing very deeply> It doesn't even come with one of those dreaded make files from the Unix-guys <grin>, but with a special build tool that you have to build yourself <oh, no> ...wait, here it says you can download a pre-built version <phew>. Already pretty non-standard for Windows so far. But now this tool spits out that something is incorrectly configured so it can't do whatever it meant to do with something called Python lib. <what's this> Besides the obvious questions left open ("What did I do wrong?" "Should I have configured this?" "Where?") the most fundamental question is: "What does that mean?" Someome testing boost due to hearsay won't know what "Boost.Python" is. Is it something that the build tool needs? Something that the lib needs? /I/ knew it was one of the libs boost came with (which I wasn't interested in.) Others don't.
Next thing it emits is don't know how to make bjam Yikes! What does that mean? It surely doesn't mean it wants to compile/link bjam as I am /running/ it already, right? Scary.
No, it means that you typed an extra "bjam" on your command-line. I really don't know what we could do to make it clearer that you're not supposed to do that.
Nothing. This was my fault.
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. Yet, that's the problem of having to learn how to use a special tool just to use a lib. I'm not saying that Boost.Build wasn't a good idea. The regression testing with dozens of compilers times dozens of libs really is very impressing and I'm sure it would have been a lot harder to do this in other ways. What you did was great -- but I don't want to have to deal with it. I just want to /use/ these libs, not test them on dozens of platforms.
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.
Now I am really really baffled. I mean, I pasted that line from the guide (except for replacing "gcc" with what I thought the guide says I need to replace it with).
If you misread the guide sufficiently badly, it's possible to produce arbitrarily bad outcomes. Of course, if you're misreading the guide it's the guide's fault. But how could we have made it clearer? It's hard for me to see how we led you to invent the command line you used.
<g> See, I have little spare time. So I try things out while I'm waiting for the compiler. I don't have too much time for a given test this way and my mind is wandering. (Did the build just fail?) Of course, if I really needed to use a boost lib that needs to be built, I'd take more time. But if you want people to check things out (and if you want more users, you want this), it should be possible to do so without having to read all of the Boost.Build docs and understand yet another tool (that they won't encounter anywhere else).
Doesn't that thing even recognise its options? Finally, it advices ...patience... Oh good. So I'll wait. Further: ...found 4471 targets... ...updating 1123 targets... ...can't find 2 targets... Um, what are targets?
Standard build-system-eze for "element of the build dependency graph." These messages are inherited from jam; should we remove them?
I don't think so. But maybe some explanation in the docs (in non-build-system-eze) of what they are would be good. (I suppose that's obj files as well as lib files? Even boost doesn't have more than 4000 libs.)
Why does it only "update" a quarter of them?
The others are up-to-date.
I thought that much. I suppose I had tried to build before and forgot about it when I wrote that posting.
Why wouldn't it find 2 of them?
I'm still amazed by this, BTW.
I read the guide again. Damn! I messed this up! I need to pass "vc", not "VC71_ROOT"! The guid is a bit terse in that area...
Where did you get the idea you needed to pass "vc"? This is not a criticism; we need to know how you were led into this so we can figure out how to fix it.
I'm still unable to understand the sentence "Invoke the build system, specifying the toolset(s) you wish to use, to build and install." (step #5) in any other way. The examples below used "gcc", I figured I should replace this by "vc", which was to be found in the table right above this (step #3).
CTRL-C C:\Temp\Download\boost\boost_1_32_0>..\bjam.exe bjam "-sTOOLS=vc" stage Alas, same result. Excep that now it don't know how to make -sTOOLS=vc
It's that extra "bjam" again.
Yeah, meanwhile I know. :)
Huh? Well, it says I should be patient, so I just let it do whatever it does. There really are a few libs in "bin" at the end. And the thing says ...updated 1120 targets... Mhmm. Three missing. It might have even emitted an error message. No way I'm going to wade through 3-4k lines of messages to find those three.
Should the tool be silent while building unless it encounters an error?
Perhaps a string of dots, just so you know there's progress?
I honestly don't know. I'm used to see so many messages. (I'm mostly working on a 700kLOC project lately.) But in my IDE I know how to find the errors. Even if I had piped the output into some log file, would grepping for "error" help? Or is it "target"?
Now I would need to link to this stuff. But where exactly do I need to point my linker at?
Really, is there something unclear about http://www.boost.org/more/getting_started.html#Build_Install ??
Yes, of course.
The default build and install attempts to build all available libraries and install to default locations the libraries and Boost header files. On Unix systems the default install location is "/usr/local", and on Windows systems the default is "C:\Boost". Within those directories libraries are installed to the "lib" subdirectory, and headers to an "include/boost-1_31" subdirectory, the version will reflect the distribution you are installing.
I didn't start the intall, because I'd hate to have the stuff at "C:\Boost". But that wasn't the problem. I found the stuff in the "bin" folder.
I can't imagine how we could make this clearer. Can you help?
See below.
The guide has something on automatic linking on Windows, but I can't find where in the folder hierarchy this assumes I'm anchored.
I don't know what you mean by "anchored." I would assume that the dynamic libraries need to be in your PATH, and that's all. But I'm not an expert in this area.
Sorry for the bad wording. (I'm German.) I need to tell the IDE where it finds the libs. Now that I think of it, the install target might have just copied all lib files into the same folder and I should have pointed my IDE there. But I didn't want to use this, as I hate to have too many things in the drive's root. So yesterday I was wondering whether the autolink would name the libs with a folder like "release\runtime-link-static\libboost_filesystem-vc71-s-1_32.lib" Maybe I should just have used the installer and be done with this. But then I thought I am not all that dumb. I have read and even understood makefiles, have built things from the command line, have used 3rd-party libs without needing expensive commercial support, and I remember hacking batch files in the DOS days.
[...]
I have seen guides that weren't written for mere insiders.
Now wait a minute. Whatever it's failings, this guide was written specifically for non-insiders.
I know that this was the intention. I'm just telling the tale of me failing despite this.
[...] Can you help us understand what to change?
I'll try. First, the numbering is odd. It's unclear where a step (if it's numbered in a How-To guide, I assume it to be steps that I need to follow) begins and where it ends. Not everything having a number really is a step. For example, #2 isn't a step, but some explanation. "Step" #3 is a table supporting the header above it ("Configuring the tools"). It wearing a new number made me think it explains some new step yesterday, but since it doesn't explain what this (supposed) step would be, I felt free to guess and thus copied the 'VC71_ROOT' just in case -- which then I used at the wrong place. Having #4 (chdir) being its own step seems silly. In #5, the "stage" is mentioned. Now I think this wasn't all that good as it lead me to believe I could use it without really understanding what the build system does and how. IMHO it should either be removed or better explained what to do with the outcome of it. (I only just found that "stage" actually copies the libs into a common folder /after/ I finished this paragraph. It actually is described in a table following "The build and install system can be controlled through a set of options..." which I didn't bother to read, as I didn't want to learn how to fully make use of it. I just wanted to get up and running.) Further, the different header levels are easy to confuse by the font types and sizes used. There's a nice overview at the beginning of the page showing all this, but this doesn't help me when I'm in the middle of the page. (I had to scroll back and forth several times today to finally understand why the toolset table apears twice. 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. 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. 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. Also, for a "Getting Started" guide a link to some explanation of how to access CVS would do. No need to clutter the beginner's guide with info that 98% of the beginners won't need. The "Results" section I actually consider very well written and easy to understand. However, it's almost 1/3rd of the whole guide and it's hard to remember you're in the middle of it when you read the doc for the first time. Now I really think this page should be broken. The same goes for "Automatic Linking on Windows". Why should users of all other platforms have to read this? (BTW, the auto-link anchor seems to be missing. The link from the top of the page doesn't work.) OK, I understand that that's a lot of vague chriticism. So here's an outline of what I would have expected: 1. Download the lib from <link>, unzip it. If you want to use the header-only libs, goto #4.2. If you want to use (one of) the following libs - ... - ... ... you need to build them. 2. Boost is built using a special tool. Either download bjam as a pre-built binary from <link>, or download its sources and follow the instructions at <link> to build it yourself. Make sure a bjam executable is in either your path or the current directory. 3. Pick the tool name for your platform/compiler/ std lib from the nth column of following table: <table> (If your platform/compiler/std lib isnt in this table you can't follow this guide. Please look here <link> for how to setup things yourself.) Invoke bjam like this: bjam "-sTOOLS=<tool_name>" install replacing <tool_name> with the name picked from the table. Here <link> is an explanation of common messages of bjam and what they mean. Here <link> is a documentation of what else you can do with bjam. 4. The libs are built. 4.1. Point your linker to <folder> for the libs. Here <link> is an explanation of the names of the built libraries. Windows compiler can automatically pick up the libarary needed. Here <link> is explained how this works. 4.2. Point your compiler to <folder> for the headers. 5. The documentation for all libs shipped with boost can be found at <folder>/index.html. 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. Other libs we use come with project files for all the platforms we need them for and we just add them to the project. That's very easy. Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
On Thu, May 26, 2005 at 01:08:10PM +0200, Hendrik Schober wrote:
David Abrahams <dave@boost-consulting.com> wrote:
Where did you get the idea you needed to pass "vc"? This is not a criticism; we need to know how you were led into this so we can figure out how to fix it.
I'm still unable to understand the sentence "Invoke the build system, specifying the toolset(s) you wish to use, to build and install." (step #5) in any other way. The examples below used "gcc", I figured I should replace this by "vc", which was to be found in the table right above this (step #3).
No it isn't! You _still_ haven't bothered to read that table! It's really not hard. You're told to pick a toolset to use with the -sTOOLS option and the table says "TOOLS name" in the column heading. It doesn't say "click a column in the table and then pick a variable from the table on the next page" jon
Jonathan Wakely <cow@compsoc.man.ac.uk> wrote:
On Thu, May 26, 2005 at 01:08:10PM +0200, Hendrik Schober wrote:
David Abrahams <dave@boost-consulting.com> wrote:
Where did you get the idea you needed to pass "vc"? This is not a criticism; we need to know how you were led into this so we can figure out how to fix it.
I'm still unable to understand the sentence "Invoke the build system, specifying the toolset(s) you wish to use, to build and install." (step #5) in any other way. The examples below used "gcc", I figured I should replace this by "vc", which was to be found in the table right above this (step #3).
No it isn't! You _still_ haven't bothered to read that table!
1. Why should I? I'm the novice's advocate here. :) 2. I did read it.
It's really not hard. You're told to pick a toolset to use with the -sTOOLS option and the table says "TOOLS name" in the column heading.
That's why I (eventually) picked the entry under "TOOLS name" and used it together with the "-sTOOLS" option. <surprised> Was that wrong, too? Or did you misread my mail(s)?
It doesn't say "click a column in the table and then pick a variable from the table on the next page"
No, it doesn't. (However, it does say "For information about configuring each toolset, click its name in the leftmost column." And we're under the header "Configuring the tools" here.) Note: I'm not saying that what's written there is plain wrong or even written to mislead people. What I said is that I, by quick reading, read wrong. And obviously I wasn't the only one who failed to build the libs at first attempt. Now you can all go and say this isn't for the faint of heart who don't read carefully -- and you're going to lose many potential users who use other libraries without many problems. Or you can say you want this as easy as possible so that it will get widely used. Then you should make it easier. (You won't lose me either way. I am using some of boost for quite a while and I am sure I would find a way to build the libs that require it if I spent enough time.)
jon
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
On Thu, May 26, 2005 at 02:21:03PM +0200, Hendrik Schober wrote:
Jonathan Wakely <cow@compsoc.man.ac.uk> wrote:
On Thu, May 26, 2005 at 01:08:10PM +0200, Hendrik Schober wrote:
David Abrahams <dave@boost-consulting.com> wrote:
Where did you get the idea you needed to pass "vc"? This is not a criticism; we need to know how you were led into this so we can figure out how to fix it.
I'm still unable to understand the sentence "Invoke the build system, specifying the toolset(s) you wish to use, to build and install." (step #5) in any other way. The examples below used "gcc", I figured I should replace this by "vc", which was to be found in the table right above this (step #3).
No it isn't! You _still_ haven't bothered to read that table!
1. Why should I? I'm the novice's advocate here. :)
Fair point :-)
2. I did read it.
It's really not hard. You're told to pick a toolset to use with the -sTOOLS option and the table says "TOOLS name" in the column heading.
That's why I (eventually) picked the entry under "TOOLS name" and used it together with the "-sTOOLS" option. <surprised> Was that wrong, too? Or did you misread my mail(s)?
I read this:
figured I should replace this by "vc", which was to be found in the table right above this (step #3).
to mean you used "vc", which isn't in the table. Maybe you mis-typed it, in which case I apologise for the rant. jon -- "the chances of finding out what really is going on are so absurdly remote that the only thing to do is to say hang the sense of it and just keep yourself occupied" - Slartibartfast, "Hitch-Hiker's Guide to the Galaxy"
Jonathan Wakely <cow@compsoc.man.ac.uk> wrote:
[...] I read this:
figured I should replace this by "vc", which was to be found in the table right above this (step #3).
to mean you used "vc", which isn't in the table.
Mhmm. I think even I did. But please don't ask me why. :o>
Maybe you mis-typed it, in which case I apologise for the rant.
OK. I think there really is something to be said for the first-read-carefully approach. However, I still maintain that I was able to get up and running much easier with other libs. (Among those where, e.g., wxWidgets, STLport and Dinkumware.)
jon
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
"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?
After quite a pause ("what's it doing now?")
Good point; we should have it say something.
I supposed it checked some dependencies.
Actually no. That's what it's doing during ...patience... During the initial pause it's actually processing the instructions in all the Jamfiles, just building an internal representation of the projects and dependencies among targets.
I don't think this pause was very distracting to me. But a short note would do a lot for many people.
What should it say?
[...]
Mhmm. Do I need this? Will it even work without Python? (I know it will. But not from the guide.)
Well the message you *actually* get is:
skipping Boost.Python library build due to _missing_ _or_ _incorrect_ configuration
followed by some other stuff. So if that is insufficient to make it clear that the build will will work even without Python, what do we need to do in order to make it clear?
Suppose you never heard of boost until this fellow told you you should check it out. You download it. The "Getting Start(l)ed" guide says it needs to get built before you can use it. <sigh> It doesn't come with a project for your IDE. <breathing very deeply> It doesn't even come with one of those dreaded make files from the Unix-guys <grin>, but with a special build tool that you have to build yourself <oh, no> ...wait, here it says you can download a pre-built version <phew>. Already pretty non-standard for Windows so far. But now this tool spits out that something is incorrectly configured so it can't do whatever it meant to do with something called Python lib. <what's this>
Besides the obvious questions left open ("What did I do wrong?" "Should I have configured this?" "Where?") the most fundamental question is: "What does that mean?" Someome testing boost due to hearsay won't know what "Boost.Python" is. Is it something that the build tool needs? Something that the lib needs? /I/ knew it was one of the libs boost came with (which I wasn't interested in.) Others don't.
Yes, I understand all that. Let me ask again: So if that is insufficient to make it clear that the build will will work even without Python, what do we need to do in order to make it clear?
Next thing it emits is don't know how to make bjam Yikes! What does that mean? It surely doesn't mean it wants to compile/link bjam as I am /running/ it already, right? Scary.
No, it means that you typed an extra "bjam" on your command-line. I really don't know what we could do to make it clearer that you're not supposed to do that.
Nothing. This was my fault.
What about the color thing?
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.
Yet, that's the problem of having to learn how to use a special tool just to use a lib. I'm not saying that Boost.Build wasn't a good idea. The regression testing with dozens of compilers times dozens of libs really is very impressing and I'm sure it would have been a lot harder to do this in other ways. What you did was great -- but I don't want to have to deal with it. I just want to /use/ these libs, not test them on dozens of platforms.
Understood.
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.
Now I am really really baffled. I mean, I pasted that line from the guide (except for replacing "gcc" with what I thought the guide says I need to replace it with).
If you misread the guide sufficiently badly, it's possible to produce arbitrarily bad outcomes. Of course, if you're misreading the guide it's the guide's fault. But how could we have made it clearer? It's hard for me to see how we led you to invent the command line you used.
<g> See, I have little spare time. So I try things out while I'm waiting for the compiler. I don't have too much time for a given test this way and my mind is wandering. (Did the build just fail?) Of course, if I really needed to use a boost lib that needs to be built, I'd take more time. But if you want people to check things out (and if you want more users, you want this), it should be possible to do so without having to read all of the Boost.Build docs and understand yet another tool (that they won't encounter anywhere else).
Good point.
Doesn't that thing even recognise its options? Finally, it advices ...patience... Oh good. So I'll wait. Further: ...found 4471 targets... ...updating 1123 targets... ...can't find 2 targets... Um, what are targets?
Standard build-system-eze for "element of the build dependency graph." These messages are inherited from jam; should we remove them?
I don't think so. But maybe some explanation in the docs (in non-build-system-eze) of what they are would be good.
Why shouldn't the tool output messages in non-build-system-ese? I have seldom seen a use for the "found... updatinig... can't find..." messages. Maybe we should only give those if you request diagnostic output.
(I suppose that's obj files as well as lib files? Even boost doesn't have more than 4000 libs.)
Sources and headers too. Leaves are nodes in the graph too.
Why does it only "update" a quarter of them?
The others are up-to-date.
I thought that much. I suppose I had tried to build before and forgot about it when I wrote that posting.
Probably most of those were leaves.
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.
I read the guide again. Damn! I messed this up! I need to pass "vc", not "VC71_ROOT"! The guid is a bit terse in that area...
Where did you get the idea you needed to pass "vc"? This is not a criticism; we need to know how you were led into this so we can figure out how to fix it.
I'm still unable to understand the sentence "Invoke the build system, specifying the toolset(s) you wish to use, to build and install." (step #5) in any other way. The examples below used "gcc", I figured I should replace this by "vc", which was to be found in the table right above this (step #3).
No, not in that table. There's one in http://www.boost.org/more/getting_started.html#Results, which comes *after* step 5. I can see how, if you're in a hurry, you might lose your place and mistake the meaning of that table. I think we ought to change the column headings somehow and provide an overall table caption that helps to disambiguate it.
CTRL-C C:\Temp\Download\boost\boost_1_32_0>..\bjam.exe bjam "-sTOOLS=vc" stage Alas, same result. Excep that now it don't know how to make -sTOOLS=vc
It's that extra "bjam" again.
Yeah, meanwhile I know. :)
Huh? Well, it says I should be patient, so I just let it do whatever it does.
It really should say "evaluating dependencies" here.
There really are a few libs in "bin" at the end. And the thing says ...updated 1120 targets... Mhmm. Three missing. It might have even emitted an error message. No way I'm going to wade through 3-4k lines of messages to find those three.
Should the tool be silent while building unless it encounters an error?
Perhaps a string of dots, just so you know there's progress?
I honestly don't know.
Well, what do you think? I mean, of course, dots while there's success, and error messages when there are errors.
I'm used to see so many messages. (I'm mostly working on a 700kLOC project lately.) But in my IDE I know how to find the errors. Even if I had piped the output into some log file, would grepping for "error" help?
It would help if you're looking for errors and your compiler puts "error" in each error message.
Or is it "target"?
Not sure what you're after, so I can't tell you what to look for.
Now I would need to link to this stuff. But where exactly do I need to point my linker at?
Really, is there something unclear about http://www.boost.org/more/getting_started.html#Build_Install ??
Yes, of course.
The default build and install attempts to build all available libraries and install to default locations the libraries and Boost header files. On Unix systems the default install location is "/usr/local", and on Windows systems the default is "C:\Boost". Within those directories libraries are installed to the "lib" subdirectory, and headers to an "include/boost-1_31" subdirectory, the version will reflect the distribution you are installing.
I didn't start the intall, because I'd hate to have the stuff at "C:\Boost".
Did you not notice the word "default?" Of course, not giving an indication of how to get behavior other than the default, knowing that it's only a default is not much help to you, is it?
But that wasn't the problem. I found the stuff in the "bin" folder.
Well, if you subvert the things we do to make it easy for you (install) and instead start grabbing things from our implementation-detail directories, I think you forfeit the right to expect it to be simple.
I can't imagine how we could make this clearer. Can you help?
See below.
The guide has something on automatic linking on Windows, but I can't find where in the folder hierarchy this assumes I'm anchored.
I don't know what you mean by "anchored." I would assume that the dynamic libraries need to be in your PATH, and that's all. But I'm not an expert in this area.
Sorry for the bad wording. (I'm German.) I need to tell the IDE where it finds the libs. Now that I think of it, the install target might have just copied all lib files into the same folder and I should have pointed my IDE there.
Bingo.
But I didn't want to use this, as I hate to have too many things in the drive's root. So yesterday I was wondering whether the autolink would name the libs with a folder like "release\runtime-link-static\libboost_filesystem-vc71-s-1_32.lib" Maybe I should just have used the installer and be done with this.
Yes.
But then I thought I am not all that dumb. I have read and even understood makefiles, have built things from the command line, have used 3rd-party libs without needing expensive commercial support, and I remember hacking batch files in the DOS days.
You seem a little schitzophrenic about whether you're able to handle make-like things, now ;-)
[...]
I have seen guides that weren't written for mere insiders.
Now wait a minute. Whatever it's failings, this guide was written specifically for non-insiders.
I know that this was the intention. I'm just telling the tale of me failing despite this.
I get it.
[...] Can you help us understand what to change?
I'll try.
First, the numbering is odd. It's unclear where a step (if it's numbered in a How-To guide, I assume it to be steps that I need to follow) begins and where it ends.
Really?
Not everything having a number really is a step. For example, #2 isn't a step, but some explanation.
Well it is a step, but it needs a title: "Get Boost.Jam" I actually see the 2 as going with "Preparation," but it's not obvious why I see it that way.
"Step" #3 is a table supporting the header above it ("Configuring the tools"). It wearing a new number made me think it explains some new step yesterday, but since it doesn't explain what this (supposed) step would be, I felt free to guess and thus copied the 'VC71_ROOT' just in case -- which then I used at the wrong place.
This is a good point. I wonder how I never noticed it.
Having #4 (chdir) being its own step seems silly.
:)
In #5, the "stage" is mentioned. Now I think this wasn't all that good as it lead me to believe I could use it without really understanding what the build system does and how.
From my reading, it's not all that clear what the difference between "stage" and "install" is. We should tell the user explicitly that "stage" does *not* copy Boost header files.
IMHO it should either be removed or better explained what to do with the outcome of it. (I only just found that "stage" actually copies the libs into a common folder /after/ I finished this paragraph. It actually is described in a table following "The build and install system can be controlled through a set of options..." which I didn't bother to read, as I didn't want to learn how to fully make use of it. I just wanted to get up and running.)
Understood. It's not always easy to fine-tune how much information we should give to the casual user up-front.
Further, the different header levels are easy to confuse by the font types and sizes used.
Yup.
There's a nice overview at the beginning of the page showing all this, but this doesn't help me when I'm in the middle of the page.
Yeah, I favor the style used in http://boost-consulting.com/mplbook/, where each heading in the text links you back to the index so you can see where you are.
(I had to scroll back and forth several times today to finally understand why the toolset table apears twice.
...and still didn't get it, apparently. Our problem, not yours.
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.
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.
Also, for a "Getting Started" guide a link to some explanation of how to access CVS would do. No need to clutter the beginner's guide with info that 98% of the beginners won't need.
Also very good. That stuff belongs on its own page, and not just for the beginners' sake.
The "Results" section I actually consider very well written and easy to understand. However, it's almost 1/3rd of the whole guide and it's hard to remember you're in the middle of it when you read the doc for the first time. Now I really think this page should be broken.
OK.
The same goes for "Automatic Linking on Windows". Why should users of all other platforms have to read this?
Maybe because more than 90% of all C++ developers target windows (sometimes among others). This is an actual statistic, not just my off-the-cuff estimate.
(BTW, the auto-link anchor seems to be missing. The link from the top of the page doesn't work.)
Thanks.
OK, I understand that that's a lot of vague chriticism.
No, no, it's very concrete and helpful!
So here's an outline of what I would have expected:
1. Download the lib from <link>, unzip it. If you want to use the header-only libs, goto #4.2. If you want to use (one of) the following libs - ... - ... ... you need to build them.
2. Boost is built using a special tool. Either download bjam as a pre-built binary from <link>, or download its sources and follow the instructions at <link> to build it yourself. Make sure a bjam executable is in either your path or the current directory.
3. Pick the tool name for your platform/compiler/ std lib from the nth column of following table: <table> (If your platform/compiler/std lib isnt in this table you can't follow this guide. Please look here <link> for how to setup things yourself.) Invoke bjam like this: bjam "-sTOOLS=<tool_name>" install replacing <tool_name> with the name picked from the table. Here <link> is an explanation of common messages of bjam and what they mean. Here <link> is a documentation of what else you can do with bjam.
4. The libs are built. 4.1. Point your linker to <folder> for the libs. Here <link> is an explanation of the names of the built libraries. Windows compiler can automatically pick up the libarary needed. Here <link> is explained how this works. 4.2. Point your compiler to <folder> for the headers.
5. The documentation for all libs shipped with boost can be found at <folder>/index.html.
Excellent! Can I give you CVS access so you can try making a modified page? (send me your SF user name)
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.
Other libs we use come with project files for all the platforms we need them for and we just add them to the project. That's very easy.
I'd like to get to generating project files automatically eventually. Unfortunately, that's some ways off still. -- Dave Abrahams Boost Consulting www.boost-consulting.com
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
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
David Abrahams wrote:
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: [...] 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.
OK. Agree.
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?
Yes.
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?
Except that I'd think we would have an equivalent set of instructions for BBv2. Of course those instructions are less involved as setting up the toolsets is easier, and hopefully it can be automatic. -- -- 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
Rene Rivera wrote:
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
David Abrahams wrote:
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?
Yes.
Done. -- -- 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
Rene Rivera <grafik.list@redshift-software.com> writes:
Rene Rivera wrote:
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
David Abrahams wrote:
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? Yes.
Done.
You rock, as usual, man. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
Rene Rivera wrote:
David Abrahams wrote:
[snip]
Does that mean you're doing it?
Yes.
Done.
You rock, as usual, man.
Except now bjam won't build itself. Typing either "build msvc" or "build mingw" in the jam_src directory builds bootstrap\jam0.exe, which then fails to produce a bjam.exe file. Revertin the changes done in jam.c makes it work again. -- /Brian Riis
Brian Ravnsgaard Riis wrote:
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
Rene Rivera wrote:
David Abrahams wrote:
[snip]
Does that mean you're doing it?
Yes.
Done.
You rock, as usual, man.
Except now bjam won't build itself. Typing either "build msvc" or "build mingw" in the jam_src directory builds bootstrap\jam0.exe, which then fails to produce a bjam.exe file. Revertin the changes done in jam.c makes it work again.
Ouch.. Since I always build with more options it works. I'll look into it. -- -- 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
Rene Rivera wrote:
Brian Ravnsgaard Riis wrote:
Except now bjam won't build itself. Typing either "build msvc" or "build mingw" in the jam_src directory builds bootstrap\jam0.exe, which then fails to produce a bjam.exe file. Revertin the changes done in jam.c makes it work again.
Ouch.. Since I always build with more options it works. I'll look into it.
OK, fixed now. -- -- 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
On Thu, May 26, 2005 at 12:05:09PM -0400, David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
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.
See http://www.compsoc.man.ac.uk/~cow/tmp/getting_started.html for an example (including the patch I'm going to submit to change the example to use vc-7_1 not gcc) If the prompt is included there it should also be added to all the commands on the page, such as the chdir command just above (and the directory names should be made consistent) jon -- Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. - M.A. Jackson
Rene Rivera <grafik.list@redshift-software.com> wrote:
[...]
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.
<trying to play down my own silly error> Really, this was a very silly one. I don't think you can do anything for someone who's to stupid to cut and paste a command line. And if someone can't tell the prompt from the command line, I don't think there's much you can do either.
[...]
Maybe I should just have used the installer and be done with this.
Yes.
Perhaps the example should be "install" not "stage"?
They're both there. I just disagreed with using the installer, as I didn't know what it would do to my system. (I only tried this out for the sake of this thread, you know.) And "stage" happened to be the only other example on the page, so I assumed it would do this.
[...] Agreed.. Not sure I have the time for doing that now though. So help will be much appreciated :-)
I will try. Where do I have to start?
[...]
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.
<nod nod>
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 :-)
Er, we check out the headers for every project. The one lib we need to build (regex) came with a make file that was rather easily incorporated into our IDE's project files. (Or did someone here make up the make file? No, I think John provided it.) If we were ever going to use other libs that need to be built, how do we incorporate the build project into different IDEs?
[...] And I've seen mentioned here before the option of running bjam from within the IDE when a library is needed.
Yes, I guess this would be it. I hope it is possible from all IDEs to invoke external commands...
HTH.
Yes, thanks! Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
"David Abrahams" <dave@boost-consulting.com> wrote in message news:usm0aujbq.fsf@boost-consulting.com...
[...]
Mhmm. Do I need this? Will it even work without Python? (I know it will. But not from the guide.)
Well the message you *actually* get is:
skipping Boost.Python library build due to _missing_ _or_ _incorrect_ configuration (which I wasn't interested in.) Others don't. [...]
Yes, I understand all that. Let me ask again:
So if that is insufficient to make it clear that the build will will work even without Python, what do we need to do in order to make it clear?
I've no idea if this is doable. Display a summary with three sections: Successful, Skipped and Failed. Entries under the Failed heading could have a short description of the problem if possible. Jeff Flinn
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:usm0aujbq.fsf@boost-consulting.com...
[...]
Mhmm. Do I need this? Will it even work without Python? (I know it will. But not from the guide.)
Well the message you *actually* get is:
skipping Boost.Python library build due to _missing_ _or_ _incorrect_ configuration (which I wasn't interested in.) Others don't. [...]
Yes, I understand all that. Let me ask again:
So if that is insufficient to make it clear that the build will will work even without Python, what do we need to do in order to make it clear?
I've no idea if this is doable. Display a summary with three sections: Successful, Skipped and Failed. Entries under the Failed heading could have a short description of the problem if possible.
If we skip Boost.Python we *do* need to tell people what they need to set up in order to not get it to be skipped. Maybe you don't care, but I do. I was the one fielding all the "Can't build Boost.Python" questions before I had that big message. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Thu, 26 May 2005 13:27:13 -0400 David Abrahams <dave@boost-co
If we skip Boost.Python we *do* need to tell people what they need to set up in order to not get it to be skipped. Maybe you don't care, but I do. I was the one fielding all the "Can't build Boost.Python" questions before I had that big message.
Right, but I'd like to give the build an option that says "I don't care if python can't be built, so don't yell at me when you can't build it." Of course, I'd like the real option to be a tad shorter ;-)
Jody Hagins wrote:
On Thu, 26 May 2005 13:27:13 -0400 David Abrahams <dave@boost-co
If we skip Boost.Python we *do* need to tell people what they need to set up in order to not get it to be skipped. Maybe you don't care, but I do. I was the one fielding all the "Can't build Boost.Python" questions before I had that big message.
Right, but I'd like to give the build an option that says "I don't care if python can't be built, so don't yell at me when you can't build it." Of course, I'd like the real option to be a tad shorter ;-)
That option is "--without-python". Unfortunately it still gives you the warning even if one asks not to build it. -- -- 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
Rene Rivera <grafik.list@redshift-software.com> writes:
Jody Hagins wrote:
On Thu, 26 May 2005 13:27:13 -0400 David Abrahams <dave@boost-co
If we skip Boost.Python we *do* need to tell people what they need to set up in order to not get it to be skipped. Maybe you don't care, but I do. I was the one fielding all the "Can't build Boost.Python" questions before I had that big message. Right, but I'd like to give the build an option that says "I don't care if python can't be built, so don't yell at me when you can't build it." Of course, I'd like the real option to be a tad shorter ;-)
That option is "--without-python". Unfortunately it still gives you the warning even if one asks not to build it.
Easily fixed. Will handle. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Rene Rivera <grafik.list@redshift-software.com> writes:
Jody Hagins wrote:
On Thu, 26 May 2005 13:27:13 -0400 David Abrahams <dave@boost-co
If we skip Boost.Python we *do* need to tell people what they need to set up in order to not get it to be skipped. Maybe you don't care, but I do. I was the one fielding all the "Can't build Boost.Python" questions before I had that big message. Right, but I'd like to give the build an option that says "I don't care if python can't be built, so don't yell at me when you can't build it." Of course, I'd like the real option to be a tad shorter ;-)
That option is "--without-python". Unfortunately it still gives you the warning even if one asks not to build it.
Easily fixed. Will handle.
Done -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 11:10 2005-05-26, you wrote:
On Thu, 26 May 2005 13:27:13 -0400 David Abrahams <dave@boost-co
If we skip Boost.Python we *do* need to tell people what they need to set up in order to not get it to be skipped. Maybe you don't care, but I do. I was the one fielding all the "Can't build Boost.Python" questions before I had that big message.
Right, but I'd like to give the build an option that says "I don't care if python can't be built, so don't yell at me when you can't build it." Of course, I'd like the real option to be a tad shorter ;-)
I submit that if you know enough to use the option, you know enough to ignore the warning. It's not like you're installing/building boost many times a day (you'd have to be _crazy_ to do that, lol).
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Jody Hagins <jody-boost-011304@atdesk.com> writes:
On Thu, 26 May 2005 13:27:13 -0400 David Abrahams <dave@boost-co
If we skip Boost.Python we *do* need to tell people what they need to set up in order to not get it to be skipped. Maybe you don't care, but I do. I was the one fielding all the "Can't build Boost.Python" questions before I had that big message.
Right, but I'd like to give the build an option that says "I don't care if python can't be built, so don't yell at me when you can't build it." Of course, I'd like the real option to be a tad shorter ;-)
--without-python ?? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uvf55q4ni.fsf@boost-consulting.com...
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:usm0aujbq.fsf@boost-consulting.com...
[...]
Mhmm. Do I need this? Will it even work without Python? (I know it will. But not from the guide.)
Well the message you *actually* get is:
skipping Boost.Python library build due to _missing_ _or_ _incorrect_ configuration (which I wasn't interested in.) Others don't. [...]
Yes, I understand all that. Let me ask again:
So if that is insufficient to make it clear that the build will will work even without Python, what do we need to do in order to make it clear?
I've no idea if this is doable. Display a summary with three sections: Successful, Skipped and Failed. Entries under the Failed heading could have a short description of the problem if possible.
If we skip Boost.Python we *do* need to tell people what they need to set up in order to not get it to be skipped. Maybe you don't care, but I do. I was the one fielding all the "Can't build Boost.Python" questions before I had that big message.
The summary could be after the existing output(including the current Boost.Python warning). It would give equal prominence to all three categories. One could then scroll up to see the specifics. Jeff Flinn
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
If we skip Boost.Python we *do* need to tell people what they need to set up in order to not get it to be skipped. Maybe you don't care, but I do. I was the one fielding all the "Can't build Boost.Python" questions before I had that big message.
The summary could be after the existing output(including the current Boost.Python warning). It would give equal prominence to all three categories. One could then scroll up to see the specifics.
Oh. That's not bad. But hard to do with bjam as currently defined. The last thing it does is update the big target dependency graph, so the output would have to be the build action for a target, and it's basically impossible to control the build order of targets unless they have a dependency relationship. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
[...] If we skip Boost.Python we *do* need to tell people what they need to set up in order to not get it to be skipped. Maybe you don't care, but I do. I was the one fielding all the "Can't build Boost.Python" questions before I had that big message.
And are there less of the "How can I build boost without having Python?" questions? :) Seriously, does that have to be told by bjam or would a note in the docs do? Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
[...] If we skip Boost.Python we *do* need to tell people what they need to set up in order to not get it to be skipped. Maybe you don't care, but I do. I was the one fielding all the "Can't build Boost.Python" questions before I had that big message.
And are there less of the "How can I build boost without having Python?" questions? :)
Yes, far less.
Seriously, does that have to be told by bjam or would a note in the docs do?
No, a note in the docs proved insufficient, which is why the message was added. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
[...]
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?
I don't think that's necessary. I was just really dumb and not paying enough atention. (I figured it would take a while for boost to get built and rushed to get it started so that I could go and have the break that I was planning to have anyway.)
[...] During the initial pause it's actually processing the instructions in all the Jamfiles, just building an internal representation of the projects and dependencies among targets.
I don't think this pause was very distracting to me. But a short note would do a lot for many people.
What should it say?
"Parsing jam file"? Or better yet: "parsing build rules"?
[...] So if that is insufficient to make it clear that the build will will work even without Python, what do we need to do in order to make it clear?
Maybe something along those lines: "Unable to find Python. Cannot build the Boost.Python lib. If you want to use Boost.Python, look at the docs at <link>. Proceeding with other libs..."
[...]
No, it means that you typed an extra "bjam" on your command-line. I really don't know what we could do to make it clearer that you're not supposed to do that.
Nothing. This was my fault.
What about the color thing?
The reason for that silly mistake was that I didn't pay enough attantion. I might have messed this up even with colors. There's little you can do if people fail on the very first word of the command line. Really. I think it's better to concentrate on more difficult stuff -- like getting all the options right.
[...]
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.
Yes, this restriction seems silly. If it's easy to fix and someone has the time to do it, think it should be done rather sooner than later. (Or at least bjam should issue an error or a warning for this.) But in the end most newbies should be able to just cut and paste a command line anyway, so I'd recommend to make this easier first.
[...]
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.
Um, I can't follow you here.
[...]
Um, what are targets?
Standard build-system-eze for "element of the build dependency graph." These messages are inherited from jam; should we remove them?
I don't think so. But maybe some explanation in the docs (in non-build-system-eze) of what they are would be good.
Why shouldn't the tool output messages in non-build-system-ese? [...]
Oh it should. I didn't say anything against that, did I?
[...]
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.
Oh, this wasn't an error? Wow, then this should surely made very clear. If a build tool says it can't find/build/update some target, I surely read an error into this message.
[...]
Where did you get the idea you needed to pass "vc"? [...]
I'm still unable to understand the sentence "Invoke the build system, specifying the toolset(s) you wish to use, to build and install." (step #5) in any other way. The examples below used "gcc", I figured I should replace this by "vc", which was to be found in the table right above this (step #3).
No, not in that table.
Yes, I saw this yesterday. What can I say? I don't know anymore where I got this from. As I said, I didn't really pay a lot of attention.
There's one in http://www.boost.org/more/getting_started.html#Results, which comes *after* step 5. I can see how, if you're in a hurry, you might lose your place and mistake the meaning of that table. I think we ought to change the column headings somehow and provide an overall table caption that helps to disambiguate it.
Better yet break the page so that I don't see bot at once.
[...]
Well, it says I should be patient, so I just let it do whatever it does.
It really should say "evaluating dependencies" here.
Actually /I/ don't care. As long as the tool is somehow making clear it's still working, I'm fine.
There really are a few libs in "bin" at the end. And the thing says ...updated 1120 targets... Mhmm. Three missing. It might have even emitted an error message. No way I'm going to wade through 3-4k lines of messages to find those three.
Should the tool be silent while building unless it encounters an error?
Perhaps a string of dots, just so you know there's progress?
I honestly don't know.
Well, what do you think? I mean, of course, dots while there's success, and error messages when there are errors.
Mhmm. Not seeing anything is always distracting. Seeing to much isn't good either. So the dots are probably a good idea.
I'm used to see so many messages. (I'm mostly working on a 700kLOC project lately.) But in my IDE I know how to find the errors. Even if I had piped the output into some log file, would grepping for "error" help?
It would help if you're looking for errors and your compiler puts "error" in each error message.
So what I need to look for is error messages that my compilers emits? Anything else? (Maybe a short "Look for error message from your compiler" in case of an error would help.)
Or is it "target"?
Not sure what you're after, so I can't tell you what to look for.
The tool said it updated 1120 of 1123 targets. It didn't say a word about what happened to the other three. If I had done this in order to reall use the resulting libs, I would have had to browse through 3-4k lines of message to find out what went wrong. (/If/ something went wrong. It didn't say it did.)
[...]
I didn't start the intall, because I'd hate to have the stuff at "C:\Boost".
Did you not notice the word "default?" Of course, not giving an indication of how to get behavior other than the default, knowing that it's only a default is not much help to you, is it?
Yes. I thought the "stage" was the indication.
But that wasn't the problem. I found the stuff in the "bin" folder.
Well, if you subvert the things we do to make it easy for you (install) and instead start grabbing things from our implementation-detail directories, I think you forfeit the right to expect it to be simple.
If it's that hard to do otherwise, then why do you give (incomplete) information on how to do so on the "Getting Started" guide?
[...]
But I didn't want to use this, as I hate to have too many things in the drive's root. So yesterday I was wondering whether the autolink would name the libs with a folder like "release\runtime-link-static\libboost_filesystem-vc71-s-1_32.lib" Maybe I should just have used the installer and be done with this.
Yes.
I suggest "stage" to be either removed or better explained.
But then I thought I am not all that dumb. I have read and even understood makefiles, have built things from the command line, have used 3rd-party libs without needing expensive commercial support, and I remember hacking batch files in the DOS days.
You seem a little schitzophrenic about whether you're able to handle make-like things, now ;-)
It's not that I've never done this. I have. But that doesn't mean it isn't a PITA to do so. Usually makfiles come with libs I need to use and usually they are pretty well prepared for what I need to do. So I just pass the to make and I'm done.
[...]
First, the numbering is odd. It's unclear where a step (if it's numbered in a How-To guide, I assume it to be steps that I need to follow) begins and where it ends.
Really?
Yes. TBH, this looks as if first there was a guide with headers and sections and later on someone came and put in the numbers in a few places that seemed important. Unfortunately that someone seems to have been very familiar with the whole process.
Not everything having a number really is a step. For example, #2 isn't a step, but some explanation.
Well it is a step, but it needs a title: "Get Boost.Jam"
That goes for all steps. They should have a number and a title. All other headers should be logically grouped on a level below those steps. (Sorry, I just don't know the correct English terms for structuring a document.)
I actually see the 2 as going with "Preparation," but it's not obvious why I see it that way.
It's under "Preparation", but so is the "Configuring the tools" header. Even worse, "Supported toolset" seems (when I look at the header's font sizes) to be under "Preparation" as well -- but it's got #3 three. That's very confusing.
"Step" #3 is a table supporting the header above it ("Configuring the tools"). It wearing a new number made me think it explains some new step yesterday, but since it doesn't explain what this (supposed) step would be, I felt free to guess and thus copied the 'VC71_ROOT' just in case -- which then I used at the wrong place.
This is a good point. I wonder how I never noticed it.
Having #4 (chdir) being its own step seems silly.
:)
In #5, the "stage" is mentioned. Now I think this wasn't all that good as it lead me to believe I could use it without really understanding what the build system does and how.
From my reading, it's not all that clear what the difference between "stage" and "install" is. We should tell the user explicitly that "stage" does *not* copy Boost header files.
For the novice, what is it good for at all? Do you want novices to use it? Should it be there at all?
IMHO it should either be removed or better explained what to do with the outcome of it. (I only just found that "stage" actually copies the libs into a common folder /after/ I finished this paragraph. It actually is described in a table following "The build and install system can be controlled through a set of options..." which I didn't bother to read, as I didn't want to learn how to fully make use of it. I just wanted to get up and running.)
Understood. It's not always easy to fine-tune how much information we should give to the casual user up-front.
Further, the different header levels are easy to confuse by the font types and sizes used.
Yup.
There's a nice overview at the beginning of the page showing all this, but this doesn't help me when I'm in the middle of the page.
Yeah, I favor the style used in http://boost-consulting.com/mplbook/, where each heading in the text links you back to the index so you can see where you are.
Wow, Firefox gave me no clue for this. I only found this out by accident when I was almost ready to give up searching and answer here that I don't know what you're talking about. :)
(I had to scroll back and forth several times today to finally understand why the toolset table apears twice.
...and still didn't get it, apparently. Our problem, not yours.
Um, actually I only scrolled back and forth the day after I posted here. When I tried this, I don't think I even noticed that I was looking at two different tables. :(
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.
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.
Also, for a "Getting Started" guide a link to some explanation of how to access CVS would do. No need to clutter the beginner's guide with info that 98% of the beginners won't need.
Also very good. That stuff belongs on its own page, and not just for the beginners' sake.
The "Results" section I actually consider very well written and easy to understand. However, it's almost 1/3rd of the whole guide and it's hard to remember you're in the middle of it when you read the doc for the first time. Now I really think this page should be broken.
OK.
The same goes for "Automatic Linking on Windows". Why should users of all other platforms have to read this?
Maybe because more than 90% of all C++ developers target windows (sometimes among others). This is an actual statistic, not just my off-the-cuff estimate.
Wow. :-o I hadn't thought this. If that's the case, you should really, really, really make it easier to build boost libs to Windows users.
[...]
So here's an outline of what I would have expected:
1. Download the lib from <link>, unzip it. If you want to use the header-only libs, goto #4.2. If you want to use (one of) the following libs - ... - ... ... you need to build them.
2. Boost is built using a special tool. Either download bjam as a pre-built binary from <link>, or download its sources and follow the instructions at <link> to build it yourself. Make sure a bjam executable is in either your path or the current directory.
3. Pick the tool name for your platform/compiler/ std lib from the nth column of following table: <table> (If your platform/compiler/std lib isnt in this table you can't follow this guide. Please look here <link> for how to setup things yourself.) Invoke bjam like this: bjam "-sTOOLS=<tool_name>" install replacing <tool_name> with the name picked from the table. Here <link> is an explanation of common messages of bjam and what they mean. Here <link> is a documentation of what else you can do with bjam.
4. The libs are built. 4.1. Point your linker to <folder> for the libs. Here <link> is an explanation of the names of the built libraries. Windows compiler can automatically pick up the libarary needed. Here <link> is explained how this works. 4.2. Point your compiler to <folder> for the headers.
5. The documentation for all libs shipped with boost can be found at <folder>/index.html.
Excellent! Can I give you CVS access so you can try making a modified page? (send me your SF user name)
Um, I knew this would come up eventually. :) I could hack something in HTML, but isn't that just generated from some other format? Sorry, boost is progressing way too fast for me to keep up with. Other than that I'd need a SF user name first. I see if I find time to put the above into some HTML this weekend. (No promise, though. I mainly want to spend the weekend with my kids.)
[...]
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
[...]
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?
I don't think that's necessary. I was just really dumb and not paying enough atention. (I figured it would take a while for boost to get built and rushed to get it started so that I could go and have the break that I was planning to have anyway.)
[...] During the initial pause it's actually processing the instructions in all the Jamfiles, just building an internal representation of the projects and dependencies among targets.
I don't think this pause was very distracting to me. But a short note would do a lot for many people.
What should it say?
"Parsing jam file"? Or better yet: "parsing build rules"?
Well, it's much more than parsing. It's actually "evaluating" or "executing" them. I think "executing" would be misleading, so maybe "evaluating" would be better.
[...] So if that is insufficient to make it clear that the build will will work even without Python, what do we need to do in order to make it clear?
Maybe something along those lines: "Unable to find Python. Cannot build the Boost.Python lib. If you want to use Boost.Python, look at the docs at <link>. Proceeding with other libs..."
It's currently: --------------------------------------------------------------------- *** If you don't need Boost.Python, you can ignore this section *** *** pass --without-python to suppress this message in the future *** skipping Boost.Python library build due to missing or incorrect configuration ... --------------------------------------------------------------------- How's that?
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.
Yes, this restriction seems silly. If it's easy to fix and someone has the time to do it, think it should be done rather sooner than later.
Rene took care of it.
(Or at least bjam should issue an error or a warning for this.) But in the end most newbies should be able to just cut and paste a command line anyway, so I'd recommend to make this easier first.
How so?
[...]
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.
Um, I can't follow you here.
Sorry, I mean, e.g., at http://www.boost.org/tools/build/v1/msvc-tools.html and all the other pages like it. These are the pages you clicked through to, and found VC_71_ROOT on.
[...]
Um, what are targets?
Standard build-system-eze for "element of the build dependency graph." These messages are inherited from jam; should we remove them?
I don't think so. But maybe some explanation in the docs (in non-build-system-eze) of what they are would be good.
Why shouldn't the tool output messages in non-build-system-ese? [...]
Oh it should. I didn't say anything against that, did I?
Well, no, but telling you that we found 4471 targets and we're updating 1123 of them has to be more cryptic than helpful!
[...]
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.
Oh, this wasn't an error? Wow, then this should surely made very clear. If a build tool says it can't find/build/update some target, I surely read an error into this message.
I guess you're right; it's an error and should stay. But we should tell you the names of the targets we can't find, right?
Well, it says I should be patient, so I just let it do whatever it does.
It really should say "evaluating dependencies" here.
Actually /I/ don't care. As long as the tool is somehow making clear it's still working, I'm fine.
Okay.
Well, what do you think? I mean, of course, dots while there's success, and error messages when there are errors.
Mhmm. Not seeing anything is always distracting. Seeing to much isn't good either. So the dots are probably a good idea.
Okay.
I'm used to see so many messages. (I'm mostly working on a 700kLOC project lately.) But in my IDE I know how to find the errors. Even if I had piped the output into some log file, would grepping for "error" help?
It would help if you're looking for errors and your compiler puts "error" in each error message.
So what I need to look for is error messages that my compilers emits?
If you want to find the error messages from your compiler, then yes. You didn't really say what you're looking for.
Anything else? (Maybe a short "Look for error message from your compiler" in case of an error would help.)
You might be looking for errors from the linker, too. I don't really understand what you're after, though. All that we output now other than error messages from your compiler is stuff like: vc-c++ <name-of-some-obj-file-target-being-created-by-compilation>
Or is it "target"?
Not sure what you're after, so I can't tell you what to look for.
The tool said it updated 1120 of 1123 targets. It didn't say a word about what happened to the other three. If I had done this in order to reall use the resulting libs, I would have had to browse through 3-4k lines of message to find out what went wrong. (/If/ something went wrong. It didn't say it did.)
Okay, so most of those messages are probably errors from your compiler or linker and you'll have to browse them anyway, but it might be helpful if we summarized at the end which targets couldn't be built, I guess.
[...]
I didn't start the intall, because I'd hate to have the stuff at "C:\Boost".
Did you not notice the word "default?" Of course, not giving an indication of how to get behavior other than the default, knowing that it's only a default is not much help to you, is it?
Yes. I thought the "stage" was the indication.
But that wasn't the problem. I found the stuff in the "bin" folder.
Well, if you subvert the things we do to make it easy for you (install) and instead start grabbing things from our implementation-detail directories, I think you forfeit the right to expect it to be simple.
If it's that hard to do otherwise, then why do you give (incomplete) information on how to do so on the "Getting Started" guide?
I don't understand the question, but you'll have to take it up with Rene. I didn't write the Getting Started guide.
[...]
But I didn't want to use this, as I hate to have too many things in the drive's root. So yesterday I was wondering whether the autolink would name the libs with a folder like "release\runtime-link-static\libboost_filesystem-vc71-s-1_32.lib" Maybe I should just have used the installer and be done with this.
Yes.
I suggest "stage" to be either removed or better explained.
I agree. I think I still don't really understand the differences between stage and install.
Not everything having a number really is a step. For example, #2 isn't a step, but some explanation.
Well it is a step, but it needs a title: "Get Boost.Jam"
That goes for all steps. They should have a number and a title. All other headers should be logically grouped on a level below those steps. (Sorry, I just don't know the correct English terms for structuring a document.)
That's correct enough.
From my reading, it's not all that clear what the difference between "stage" and "install" is. We should tell the user explicitly that "stage" does *not* copy Boost header files.
For the novice, what is it good for at all? Do you want novices to use it? Should it be there at all?
I don't know; you have to ask Rene.
Yeah, I favor the style used in http://boost-consulting.com/mplbook/, where each heading in the text links you back to the index so you can see where you are.
Wow, Firefox gave me no clue for this. I only found this out by accident when I was almost ready to give up searching and answer here that I don't know what you're talking about. :)
It's a matter of the stylesheet I use, I think. I really prefer those links to be subtle. If they looked like links I think the document would look wrong.
The same goes for "Automatic Linking on Windows". Why should users of all other platforms have to read this?
Maybe because more than 90% of all C++ developers target windows (sometimes among others). This is an actual statistic, not just my off-the-cuff estimate.
Wow. :-o I hadn't thought this. If that's the case, you should really, really, really make it easier to build boost libs to Windows users.
Yes.
[...]
So here's an outline of what I would have expected:
...
Excellent! Can I give you CVS access so you can try making a modified page? (send me your SF user name)
Um, I knew this would come up eventually. :) I could hack something in HTML, but isn't that just generated from some other format? Sorry, boost is progressing way too fast for me to keep up with. Other than that I'd need a SF user name first. I see if I find time to put the above into some HTML this weekend. (No promise, though. I mainly want to spend the weekend with my kids.)
Schobi eventually took me up on this; I hope everyone appreciates his efforts as much as I do! -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
[...]
Um, what are targets?
Standard build-system-eze for "element of the build dependency graph." These messages are inherited from jam; should we remove them?
I don't think so. But maybe some explanation in the docs (in non-build-system-eze) of what they are would be good.
Why shouldn't the tool output messages in non-build-system-ese? [...]
Oh it should. I didn't say anything against that, did I?
Well, no, but telling you that we found 4471 targets and we're updating 1123 of them has to be more cryptic than helpful!
It gives you an indication that there were errors, so you can look at the log and find where the failures occured. Some of the failing targets would be because something else failed.
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.
Oh, this wasn't an error? Wow, then this should surely made very clear. If a build tool says it can't find/build/update some target, I surely read an error into this message.
I guess you're right; it's an error and should stay. But we should tell you the names of the targets we can't find, right?
It would also be usefil to list the targets that failed to build as a summary without the targets that the failing targets are dependant upon (i.e. don't display the skipped targets in the summary).
I suggest "stage" to be either removed or better explained.
I agree. I think I still don't really understand the differences between stage and install.
A stage is what happens as part of the build process. For example, the GCC build process is split into stages, building a version of the compiler that is then used to build the next stage. For the Boost build process, stage is used to create the libraries only so you can use the headers provided in your Boost distribution. An install is what happend when the build succeeds, allowing you to place the results into a common distribution directory. This will also include other files that are required (e.g. language files). The Boost build process copies the header files into the directory you are installing to as well as building the libraries so that directory is like standard SDK/library distributions. Summing up: use stage if you want to use the headers from the place you extracted Boost to; use install if you want to use the directory where the library files are built to. Reece Haston Dunn Software Engineer, Sophos Web: www.sophos.com Sophos - protecting businesses against viruses and spam
"Reece Dunn" <msclrhd@hotmail.com> writes:
David Abrahams wrote:
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
[...]
> Um, what are targets?
Standard build-system-eze for "element of the build dependency graph." These messages are inherited from jam; should we remove them?
I don't think so. But maybe some explanation in the docs (in non-build-system-eze) of what they are would be good.
Why shouldn't the tool output messages in non-build-system-ese? [...]
Oh it should. I didn't say anything against that, did I?
Well, no, but telling you that we found 4471 targets and we're updating 1123 of them has to be more cryptic than helpful!
It gives you an indication that there were errors,
No, that's my point; it doesn't. Only 3 of those it found didn't get built. You'd still see two different numbers if everything went right.
we should tell you the names of the targets we can't find, right?
It would also be usefil to list the targets that failed to build as a summary without the targets that the failing targets are dependant upon (i.e. don't display the skipped targets in the summary).
I suggest "stage" to be either removed or better explained.
I agree. I think I still don't really understand the differences between stage and install.
A stage is what happens as part of the build process. For example, the GCC build process is split into stages, building a version of the compiler that is then used to build the next stage. For the Boost build process, stage is used to create the libraries only so you can use the headers provided in your Boost distribution.
That's not a very descriptive name, IMO, and I don't see the analogy to the GCC build stages (with which I am familiar).
An install is what happend when the build succeeds, allowing you to place the results into a common distribution directory. This will also include other files that are required (e.g. language files). The Boost build process copies the header files into the directory you are installing to as well as building the libraries so that directory is like standard SDK/library distributions.
Summing up: use stage if you want to use the headers from the place you extracted Boost to; use install if you want to use the directory where the library files are built to.
That's simple enough; we should put that description in the getting started guide. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
What should it say?
"Parsing jam file"? Or better yet: "parsing build rules"?
Well, it's much more than parsing. It's actually "evaluating" or "executing" them. I think "executing" would be misleading, so maybe "evaluating" would be better.
"Determining what needs to be built"? "Determining the work required to build Boost"?
So if that is insufficient to make it clear that the build will will work even without Python, what do we need to do in order to make it clear?
Maybe something along those lines: "Unable to find Python. Cannot build the Boost.Python lib. If you want to use Boost.Python, look at the docs at <link>. Proceeding with other libs..."
It's currently:
--------------------------------------------------------------------- *** If you don't need Boost.Python, you can ignore this section *** ^ Add a semicolon.
*** pass --without-python to suppress this message in the future ***
skipping Boost.Python library build due to missing or incorrect configuration ...
---------------------------------------------------------------------
How's that?
Looks perfect (with the semicolon).
Um, what are targets?
Standard build-system-eze for "element of the build dependency graph." These messages are inherited from jam; should we remove them?
I don't think so. But maybe some explanation in the docs (in non-build-system-eze) of what they are would be good.
Why shouldn't the tool output messages in non-build-system-ese? [...]
Oh it should. I didn't say anything against that, did I?
Well, no, but telling you that we found 4471 targets and we're updating 1123 of them has to be more cryptic than helpful!
How about something along these lines: Found 4471 items to build, of which 3348 were already current. Updated 1123 items.
Well, what do you think? I mean, of course, dots while there's success, and error messages when there are errors.
Mhmm. Not seeing anything is always distracting. Seeing to much isn't good either. So the dots are probably a good idea.
Okay.
There's always the old standby approach of printing, in succession, the following strings: "\r-" "\r\" "\r|" "\r/" repeat That avoids spewing thousands of lines or characters of output, yet gives active feedback. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
What should it say?
"Parsing jam file"? Or better yet: "parsing build rules"?
Well, it's much more than parsing. It's actually "evaluating" or "executing" them. I think "executing" would be misleading, so maybe "evaluating" would be better.
"Determining what needs to be built"?
Not really accurate.
"Determining the work required to build Boost"?
Kinda vague. I guess I'd say "building dependency graph." That's about as accurate as possible in this case.
So if that is insufficient to make it clear that the build will will work even without Python, what do we need to do in order to make it clear?
Maybe something along those lines: "Unable to find Python. Cannot build the Boost.Python lib. If you want to use Boost.Python, look at the docs at <link>. Proceeding with other libs..."
It's currently:
--------------------------------------------------------------------- *** If you don't need Boost.Python, you can ignore this section *** ^ Add a semicolon.
These are not supposed to be sentences. The semicolon adds nothing. If I were trying to follow rules for writing English prose the ***s would have to go too.
Well, no, but telling you that we found 4471 targets and we're updating 1123 of them has to be more cryptic than helpful!
How about something along these lines:
Found 4471 items to build, of which 3348 were already current. Updated 1123 items.
Not really accurate. Most of the items are sources (headers, even), so they're not "items to build." They're just nodes in the dependency graph.
There's always the old standby approach of printing, in succession, the following strings:
"\r-" "\r\" "\r|" "\r/" repeat
That avoids spewing thousands of lines or characters of output, yet gives active feedback.
Does that really work reliably and portably, or are some people going to see -\|/-\|/-\|/-\|/-\|/-\|/.... ?? I suppose it's not much worse than dots if they do. But if it comes out as - \ | / - \ | / - \ | / ... everyone's gonna be sorry. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
It's currently:
--------------------------------------------------------------------- *** If you don't need Boost.Python, you can ignore this section *** ^ Add a semicolon.
These are not supposed to be sentences. The semicolon adds nothing. If I were trying to follow rules for writing English prose the ***s would have to go too.
You capitalized the first word in the first line, but not the first in the second line. Thus, I took them as related clauses needing a semicolon. You could capitalize the first word of the second line and it would work well enough, too.
Well, no, but telling you that we found 4471 targets and we're updating 1123 of them has to be more cryptic than helpful!
How about something along these lines:
Found 4471 items to build, of which 3348 were already current. Updated 1123 items.
Not really accurate. Most of the items are sources (headers, even), so they're not "items to build." They're just nodes in the dependency graph.
I suggested two things in the above. One part explains why some weren't updated. The other tried to find an alternative for "targets" which you suggested was too cryptic. Is the rest acceptable once a good "targets" alternative is found? Found 4471 dependencies, of which 3348 were already current. Updated 1123 dependencies.
There's always the old standby approach of printing, in succession, the following strings:
"\r-" "\r\" "\r|" "\r/" repeat
That avoids spewing thousands of lines or characters of output, yet gives active feedback.
Does that really work reliably and portably, or are some people going to see
-\|/-\|/-\|/-\|/-\|/-\|/....
I suppose that there might be a dumb terminal emulator that won't do the right thing, but I wouldn't expect that to be at all common. Even emacs's shell mode, for which $TERM is "dumb," works (tested using printf "testing -"; sleep 1; printf "\rtesting \\"; sleep 1; printf "\rtesting |"; sleep 1; printf "\rtesting /"; sleep 1; printf "\rtesting...done\n" from bash). -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
It's currently:
--------------------------------------------------------------------- *** If you don't need Boost.Python, you can ignore this section *** ^ Add a semicolon.
These are not supposed to be sentences. The semicolon adds nothing. If I were trying to follow rules for writing English prose the ***s would have to go too.
You capitalized the first word in the first line, but not the first in the second line. Thus, I took them as related clauses needing a semicolon. You could capitalize the first word of the second line and it would work well enough, too.
OK.
Well, no, but telling you that we found 4471 targets and we're updating 1123 of them has to be more cryptic than helpful!
How about something along these lines:
Found 4471 items to build, of which 3348 were already current. Updated 1123 items.
Not really accurate. Most of the items are sources (headers, even), so they're not "items to build." They're just nodes in the dependency graph.
I suggested two things in the above. One part explains why some weren't updated.
That part was fine.
The other tried to find an alternative for "targets" which you suggested was too cryptic. Is the rest acceptable once a good "targets" alternative is found?
Maybe. Seems to me it would be better to give the number that were missing or out-of-date rather than the number that were current. That way, you could see the difference between that and the number updated more clearly. Of course "updated" is silly at that point, I think, because we haven't started doing any build actions yet IIRC.
Found 4471 dependencies, of which 3348 were already current. Updated 1123 dependencies.
Unfortunately, "dependencies" is wrong too. The nodes in the dependency graph includes things that are only dependents and not dependencies. And if you were to count edges in the graph (the other way to understand the word "dependency" you'd get different numbers -- ones that are even less useful).
There's always the old standby approach of printing, in succession, the following strings:
"\r-" "\r\" "\r|" "\r/" repeat
That avoids spewing thousands of lines or characters of output, yet gives active feedback.
Does that really work reliably and portably, or are some people going to see
-\|/-\|/-\|/-\|/-\|/-\|/....
I suppose that there might be a dumb terminal emulator that won't do the right thing, but I wouldn't expect that to be at all common. Even emacs's shell mode, for which $TERM is "dumb," works (tested using
printf "testing -"; sleep 1; printf "\rtesting \\"; sleep 1; printf "\rtesting |"; sleep 1; printf "\rtesting /"; sleep 1; printf "\rtesting...done\n"
from bash).
Okay, I'm all for it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
There's always the old standby approach of printing, in succession, the following strings:
"\r-" "\r\" "\r|" "\r/" repeat
Does that really work reliably and portably, or are some people going to see
-\|/-\|/-\|/-\|/-\|/-\|/....
I suppose that there might be a dumb terminal emulator that won't do the right thing, but I wouldn't expect that to be at all common. Even emacs's shell mode, for which $TERM is "dumb," works (tested using
printf "testing -"; sleep 1; printf "\rtesting \\"; sleep 1; printf "\rtesting |"; sleep 1; printf "\rtesting /"; sleep 1; printf "\rtesting...done\n"
from bash).
Okay, I'm all for it.
Question is... Does that work in CMD.EXE? -- -- 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
Rene Rivera <grafik.list@redshift-software.com> wrote:
[...]
"\r-" "\r\" "\r|" "\r/" repeat [...]
Question is... Does that work in CMD.EXE?
This works for me (Win2k): #include <cstdio> #include <windows.h> // Sleep() const char* test[] = { "\rtesting... -" , "\rtesting... \\" , "\rtesting... |" , "\rtesting... /" }; int main() { for( unsigned int u=0; u<100; ++u ) { std::printf( test[u%(sizeof(test)/sizeof(test[0]))] ); ::Sleep(100); } printf("\rtesting...done\n"); return 0; } Of course, this doesn't mean I'm sure it works in all cases. Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
David Abrahams <dave@boost-consulting.com> wrote:
[...]
"Parsing jam file"? Or better yet: "parsing build rules"?
Well, it's much more than parsing. [...]
"Determining what needs to be built"?
Not really accurate.
"Determining the work required to build Boost"?
Kinda vague.
I guess I'd say "building dependency graph." That's about as accurate as possible in this case.
Honestly, I think you're putting much too much effort into this. For one, this was only a small destraction. Further, those who know what the tool is doing exactly obviously didn't mind the pause. And those who are to be destracted by it don't know enough to appreciate these efforts. Heck, maybe even another "be patient..." would do. If I just know the thing doesn't hang but it's doing a lengthy operation everything will be a lot better than it was.
[...]
There's always the old standby approach of printing, in succession, the following strings:
"\r-" "\r\" "\r|" "\r/" repeat
[...] Does that really work reliably and portably, or are some people going to see
-\|/-\|/-\|/-\|/-\|/-\|/....
??
I suppose it's not much worse than dots if they do. But if it comes out as
- \ | / - [...]
everyone's gonna be sorry.
How about only printing Bulding Boost.Threads... ...Success. Building Boost.XYZ... ...Success. etc.? This is something to be used by developers. They have an idea of how long it takes to compile a bunch of cpp files and put them into a library and won't get nervous if the tool just eats up CPU time without emitting something for a few minutes. Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
"Hendrik Schober" <boost@HSchober.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
[...]
"Parsing jam file"? Or better yet: "parsing build rules"?
Well, it's much more than parsing. [...]
"Determining what needs to be built"?
Not really accurate.
"Determining the work required to build Boost"?
Kinda vague.
I guess I'd say "building dependency graph." That's about as accurate as possible in this case.
Honestly, I think you're putting much too much effort into this. For one, this was only a small destraction. Further, those who know what the tool is doing exactly obviously didn't mind the pause. And those who are to be destracted by it don't know enough to appreciate these efforts. Heck, maybe even another "be patient..." would do.
Okay. Just some indication that it's working on something will be enough.
If I just know the thing doesn't hang but it's doing a lengthy operation everything will be a lot better than it was.
[...]
There's always the old standby approach of printing, in succession, the following strings:
"\r-" "\r\" "\r|" "\r/" repeat
[...]
I think I've subscribed to that suggestion now.
How about only printing Bulding Boost.Threads... ...Success. Building Boost.XYZ... ...Success. etc.?
Yes, I was thinking of something similar. That will require some significant overhaul of the build system, though, including bjam, I think.
This is something to be used by developers. They have an idea of how long it takes to compile a bunch of cpp files and put them into a library and won't get nervous if the tool just eats up CPU time without emitting something for a few minutes.
True. Unless they're not used to compiling template-heavy code ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
[...]
How about only printing Bulding Boost.Threads... ...Success. Building Boost.XYZ... ...Success. etc.?
Yes, I was thinking of something similar. That will require some significant overhaul of the build system, though, including bjam, I think.
I think the revolving dash would be good enough until this will be done.
This is something to be used by developers. They have an idea of how long it takes to compile a bunch of cpp files and put them into a library and won't get nervous if the tool just eats up CPU time without emitting something for a few minutes.
True. Unless they're not used to compiling template-heavy code ;-)
:) Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
[...]
How about only printing Bulding Boost.Threads... ...Success. Building Boost.XYZ... ...Success. etc.?
Yes, I was thinking of something similar. That will require some significant overhaul of the build system, though, including bjam, I think.
I think the revolving dash would be good enough until this will be done.
Either one requires significant work. I'll look into it though. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
[...]
How about only printing Bulding Boost.Threads... ...Success. Building Boost.XYZ... ...Success. etc.?
Yes, I was thinking of something similar. That will require some significant overhaul of the build system, though, including bjam, I think.
I think the revolving dash would be good enough until this will be done.
Either one requires significant work. I'll look into it though.
So making the guide easier seems easiest. I'm working on it. Honestly. It's just that I only have one or two hours every other night, when I'm already tired. I plan to check what I have with my fellow- workers first, will probably try to improve it afterwards, and only then show it here. I guess I'll then need some help to get the things right which require knowledge of Boost.Build (which I still try to avoid to aquire, to tackle this less biased <g>) and maybe some help to put some more links into Boost.Build at the appropriate places. Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
"Hendrik Schober" <boost@HSchober.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
[...]
How about only printing Bulding Boost.Threads... ...Success. Building Boost.XYZ... ...Success. etc.?
Yes, I was thinking of something similar. That will require some significant overhaul of the build system, though, including bjam, I think.
I think the revolving dash would be good enough until this will be done.
Either one requires significant work. I'll look into it though.
So making the guide easier seems easiest.
I'm working on it. Honestly. It's just that I only have one or two hours every other night, when I'm already tired. I plan to check what I have with my fellow- workers first, will probably try to improve it afterwards, and only then show it here.
Don't be too embarrassed to give it wide exposure early, or you may find yourself correcting the corrections your fellow workers give you, and worse yet, doing work that some Boost person might have simply done for you.
I guess I'll then need some help to get the things right which require knowledge of Boost.Build (which I still try to avoid to aquire, to tackle this less biased <g>) and maybe some help to put some more links into Boost.Build at the appropriate places.
We're happy to help, of course. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
[...]
I plan to check what I have with my fellow- workers first, will probably try to improve it afterwards, and only then show it here.
Don't be too embarrassed to give it wide exposure early, or you may find yourself correcting the corrections your fellow workers give you, and worse yet, doing work that some Boost person might have simply done for you.
Um, actually I'm not afraid of embarrassment. :) (I'm German, so I have a pretty good excuse for writing silly things.) It's just that, when my fellow-workers can't follow the guide, I failed in making it better and need to do my homework better. And then there's no point in discussing such a guide here.
[...]
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
[...]
I plan to check what I have with my fellow- workers first, will probably try to improve it afterwards, and only then show it here.
Don't be too embarrassed to give it wide exposure early, or you may find yourself correcting the corrections your fellow workers give you, and worse yet, doing work that some Boost person might have simply done for you.
Um, actually I'm not afraid of embarrassment. :) (I'm German, so I have a pretty good excuse for writing silly things.) It's just that, when my fellow-workers can't follow the guide, I failed in making it better and need to do my homework better. And then there's no point in discussing such a guide here.
Unless someone here has better ideas about how to improve it, points you more directly at the homework you need to do, or just rewrites that section and posts the improved result. Anyway, I've flogged that horse enough at this point. Thanks again for your efforts! -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hendrik Schober a écrit :
How about only printing Bulding Boost.Threads... ...Success. Building Boost.XYZ... ...Success. etc.? This is something to be used by developers.
I even prefer : Bulding Boost.Threads................. ... Success Building Boost.XYZ...... ... Success With points appearing along the compilation (for each compiled file ?) to give the user the information that something is happening. -- Loïc
David Abrahams <dave@boost-consulting.com> wrote:
[...]
During the initial pause it's actually processing the instructions in all the Jamfiles, just building an internal representation of the projects and dependencies among targets.
I don't think this pause was very distracting to me. But a short note would do a lot for many people.
What should it say?
"Parsing jam file"? Or better yet: "parsing build rules"?
Well, it's much more than parsing. It's actually "evaluating" or "executing" them. I think "executing" would be misleading, so maybe "evaluating" would be better.
So you know better than me what it should say. :)
[...] So if that is insufficient to make it clear that the build will will work even without Python, what do we need to do in order to make it clear?
Maybe something along those lines: "Unable to find Python. Cannot build the Boost.Python lib. If you want to use Boost.Python, look at the docs at <link>. Proceeding with other libs..."
It's currently:
--------------------------------------------------------------------- *** If you don't need Boost.Python, you can ignore this section *** *** pass --without-python to suppress this message in the future ***
skipping Boost.Python library build due to missing or incorrect configuration ...
---------------------------------------------------------------------
How's that?
It fails to communicate soemthing very important to people who don't know boost: Boost.Python is not required when you only want to look at boost. /I/ know that Boost.XYZ means, "XYZ" is some lib I can use. Others don't know that. They just know that "something" didn't work. From "Boost.Python" they won't know whether they need it. Maybe sneaking the word "library" in there somewhere would help: "If you don't need the Boost.Python library, ..." /I/ would opt to check out boost without that lib.
[...]
(Or at least bjam should issue an error or a warning for this.) But in the end most newbies should be able to just cut and paste a command line anyway, so I'd recommend to make this easier first.
How so?
I'm in the process of trying to fail on producing a simpler "Getting Started" guide. :o>
[...]
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.
Um, I can't follow you here.
Sorry, I mean, e.g., at http://www.boost.org/tools/build/v1/msvc-tools.html and all the other pages like it. These are the pages you clicked through to, and found VC_71_ROOT on.
I didn't even know I got there. However, if you were to write instructions for every toolset you support... I wouldn't want to think this sentence any further.
[...] Well, no, but telling you that we found 4471 targets and we're updating 1123 of them has to be more cryptic than helpful!
Oh, now I understand. Yes, if the bjam actually said what was wrong and what was OK in a way that those not familiar with bjam understood it -- that would indeed be very helpful.
[...]
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.
Oh, this wasn't an error? Wow, then this should surely made very clear. If a build tool says it can't find/build/update some target, I surely read an error into this message.
I guess you're right; it's an error and should stay.
Yes, meanwhile we knoe.
But we should tell you the names of the targets we can't find, right?
Absolutely.
[...]
I'm used to see so many messages. (I'm mostly working on a 700kLOC project lately.) But in my IDE I know how to find the errors. Even if I had piped the output into some log file, would grepping for "error" help?
It would help if you're looking for errors and your compiler puts "error" in each error message.
So what I need to look for is error messages that my compilers emits?
If you want to find the error messages from your compiler, then yes. You didn't really say what you're looking for.
I was thinking of a way to find out why bjam didn't report /all/ targets finished.
Anything else? (Maybe a short "Look for error message from your compiler" in case of an error would help.)
You might be looking for errors from the linker, too. I don't really understand what you're after, though. All that we output now other than error messages from your compiler is stuff like:
vc-c++ <name-of-some-obj-file-target-being-created-by-compilation>
Then there was no indication why it reported not all targets to be finished. I consider this bad: The tool reports it failed (or at least that's how I interpreted what it said) but did not tell me why it failed to finish what target.
[...]
The tool said it updated 1120 of 1123 targets. It didn't say a word about what happened to the other three. If I had done this in order to reall use the resulting libs, I would have had to browse through 3-4k lines of message to find out what went wrong. (/If/ something went wrong. It didn't say it did.)
Okay, so most of those messages are probably errors from your compiler or linker and you'll have to browse them anyway, but it might be helpful if we summarized at the end which targets couldn't be built, I guess.
Yes. This would at least tell me what to grep for.
[...]
But that wasn't the problem. I found the stuff in the "bin" folder.
(Which I now know I wasn't supposed to look into.)
Well, if you subvert the things we do to make it easy for you (install) and instead start grabbing things from our implementation-detail directories, I think you forfeit the right to expect it to be simple.
If it's that hard to do otherwise, then why do you give (incomplete) information on how to do so on the "Getting Started" guide?
I don't understand the question, but you'll have to take it up with Rene. I didn't write the Getting Started guide.
The "stage" thing was the first one I found that seemed to allow me to change the default installation folder. I now know that this was wrong -- nut them I thought this was what I was looking for.
[...]
I suggest "stage" to be either removed or better explained.
I agree. I think I still don't really understand the differences between stage and install.
Then I strongly suggest it. <g>
[...]
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
Dave, "David Abrahams" <dave@boost-consulting.com> wrote in message news:uhdgqudpi.fsf@boost-consulting.com...
"Hendrik Schober" <SpamTrap@gmx.de> writes:
Caleb Epstein <caleb.epstein@gmail.com> wrote:
[...] I really think the Getting Started guide is more than adequate, and is concise and easy to follow. There are gigantic yellow numbers next to the important steps. [...] really how much more hand-holding does one need?
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?
...
But where did you get the idea that VC71_ROOT was a legal toolset name?
Is there a reason that all of the xxx_ROOT variables couldn't just be ROOT? Isn't the context defined by the "-sTOOLS=..." parameter? Removing these additional names would certainly reduce the users conceptual load. As I stated elsewhere, the lack of consistency in the TOOLS naming convention for VC Toolset adds confusion as well. msvc // VC6.5 can we add vc6_5? vc7 // VC7 would vc7_0 be better? vc-7_1 // VC7.1 why the dash? why not vc7_1? These variations add unnecessary perceptual complexity. Kind of like having different handles in different places on each cabinet in your kitchen. If they were all: vc6_5 vc7_0 vc7_1 the pattern is readily visible when viewing the table. The first time users comfort level goes up magnitudes. Additionally the Toolset table would be better placed immediately after the Item 5 example: 'bjam "-sTOOLS=vc7_1" stage'. Also the two different terms 'Toolset' and 'TOOLS' adds complexity as well. Using a single term for the concept and the command line parameter would further reduce conceptual load. By the way, many of these 'opinions' are based on reading the book "The Design of Everyday Things" by Donald A. Norman. Oddly enough, most(if not all) of the boost library interfaces follow guidelines discussed in the book. :-) Jeff Flinn
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
Is there a reason that all of the xxx_ROOT variables couldn't just be ROOT? Isn't the context defined by the "-sTOOLS=..." parameter? Removing these additional names would certainly reduce the users conceptual load.
As I stated elsewhere, the lack of consistency in the TOOLS naming convention for VC Toolset adds confusion as well.
msvc // VC6.5 can we add vc6_5? vc7 // VC7 would vc7_0 be better? vc-7_1 // VC7.1 why the dash? why not vc7_1?
These variations add unnecessary perceptual complexity. Kind of like having different handles in different places on each cabinet in your kitchen. If they were all:
vc6_5 vc7_0 vc7_1
the pattern is readily visible when viewing the table. The first time users comfort level goes up magnitudes. Additionally the Toolset table would be better placed immediately after the Item 5 example: 'bjam "-sTOOLS=vc7_1" stage'. Also the two different terms 'Toolset' and 'TOOLS' adds complexity as well. Using a single term for the concept and the command line parameter would further reduce conceptual load.
Yeah, as I mentioned elsewhere, all of this is a trade-off between investing in BBv1 which will be thrown out soon and spending time on better things. But if you want to volunteer to make the fixes for 1.33, I'll be happy to give guidance. You may need to do some things to preserve backward compatibility with the old variable names to avoid upsetting people. -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 04:13 2005-05-25, Stuart Dootson wrote:
[deleted] One final point - whoever came up with the autolinking scheme (think it was John Maddock?) - thank you very much - that makes life *so* much easier!
Yes, it does! It's a wonder that the committee didn't insist long ago that there be a directive in the language which would pass a name(file?) to the linker for processing. It's not like we haven't been fighting this problem since the late 1970s and it's still a compiler specific thing. Kinda makes you wonder exactly what things the committee deems important, and why (we STILL don't have #pragma once as a "standard" requirement).
HTH
Stuart Dootson
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
At 04:13 2005-05-25, Stuart Dootson wrote:
[deleted] One final point - whoever came up with the autolinking scheme (think it was John Maddock?) - thank you very much - that makes life *so* much easier!
Yes, it does! It's a wonder that the committee didn't insist long ago that there be a directive in the language which would pass a name(file?) to the linker for processing.
Maybe because nobody ever wrote a proposal for it. The committee doesn't "insist" on things. We review and approve proposals and process issues (possible problems) with the current standard. Sometimes a few interested people actually work on proposals that make things better. If you're interested in that functionality, write a proposal.
It's not like we haven't been fighting this problem since the late 1970s and it's still a compiler specific thing. Kinda makes you wonder exactly what things the committee deems important,
That's rather needlessly snide, isn't it? All these people volunteering their time to make _your_ C++ better, trying to work on so many things that so many people who *don't* volunteer their time think are really important, and all you can do is wonder out loud what we think is important? If you think it's important, make a proposal and it will get addressed.
and why (we STILL don't have #pragma once as a "standard" requirement).
Well, one reason I can think of -- aside from the obvious one that we haven't had a proposal to consider -- is that #pragma is by definition reserved for implementation-specific hooks. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u64x651m0.fsf@boost-consulting.com...
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
At 04:13 2005-05-25, Stuart Dootson wrote:
[deleted] One final point - whoever came up with the autolinking scheme (think it was John Maddock?) - thank you very much - that makes life *so* much easier!
Yes, it does! It's a wonder that the committee didn't insist long ago that there be a directive in the language which would pass a name(file?) to the linker for processing.
Maybe because nobody ever wrote a proposal for it. The committee doesn't "insist" on things. We review and approve proposals and process issues (possible problems) with the current standard. Sometimes a few interested people actually work on proposals that make things better. If you're interested in that functionality, write a proposal.
It's not like we haven't been fighting this problem since the late 1970s and it's still a compiler specific thing. Kinda makes you wonder exactly what things the committee deems important,
That's rather needlessly snide, isn't it? All these people volunteering their time to make _your_ C++ better, trying to work on so many things that so many people who *don't* volunteer their time think are really important, and all you can do is wonder out loud what we think is important? If you think it's important, make a proposal and it will get addressed.
This proposal mechanism that Dave describes above is the only way to get anything new and important into the standard. (Once in a while something new but trivial comes in from an issues list, but that is limited to really simple stuff like a missing overload.) No one is exempt from having to write a proposal to get anything non-trivial into the standard. In the back of the Library TR is a bibliography which lists the proposals which went into TR1. Look at them. That is how stuff got into TR1. None of it is there because the committee "insisted" on it. It is there because some volunteers (often Boosters) wrote proposals. --Beman
"Paul A Bristow" <pbristow@hetp.u-net.com> wrote in message news:E1DarwS-0004uN-KK@he303war.uk.vianw.net...
Recently we had a flurry of discussion of why Boost is not more widely used.
...
But if we are to interest your average Windows IDE programmer, for whom MAKE is a blank or a distant nightmare, IMO we need some much better and simpler instructions, including lots of examples of input and output, and to be as well tested as the rest of Boost code. Like it or not, these are the potential customers and I spoken to many who are put off by the 'build barrier'.
I suggest that we explicitly say that you can use all of Boost (except the ones that must have built libraries) by adding to the include list - and say exactly how in Windows IDE-ese.
Something like this as a start? For MSVC ======== Organizing boost files ====================== 1) Create a main boost directory which will contain the current and future boost library verstions. For example: C:\boost 2) Download the desired version(s) of boost (.exe or .zip files ) from http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041 to the boost directory created in step 1. 3) Extract the .exe or .zip file(s) from Step 2 into the directory from Step 1. These sub-directories should retain the boost version within it's name. For example C:\boost\boost_1_32_0 C:\boost\boost_1_31_0 Using the header only boost libraries from MSVC7.1 ================================================== Using a single version of boost header only libraries installation wide ----------------------------------------------------------------------- 1) Open an instance of MSVC 7.1 IDE. 2) Click the 'Tools | Options...' menu. 3) Select the 'Projects | VC++ Directories' item from the tree view on the left of the Options dialog. 4) Select 'Include Files' from the 'Show directories for' dropdown. 5) Double-click just below the last entry in the directory list box, and enter the path to the sub-directory for the desired version of boost. For example: C:\boost\boost_1_33_0. 6) Repeat 5 for each Platform of interest after selecting another platform from the 'Platform' dropdown. 7) Click Ok. OR Using a single version of boost header only libraries on a project by project basis ----------------------------------------------------------------------------------- 1) Open your project with the MSVC 7.1 IDE. 2) Select the desired project from the Class View or Solution View browsers. 3) Click the 'Project | Properties' menu. 4) Select 'All Configurations' from the 'Configuration' dropdown. 5) Select 'Configuration Properties | C/C++ | General' item from the tree view on the left of the '<project> Property Pages' dialog. 6) Enter the desired boost version directory name in the 'Additional Include Directories' value field in the properties listbox. For example: C:\boost\boost_1_33_0. Note that directories are delimited with ';'. 7) Click Ok. Jeff Flinn
Looks very promising for the headers only (though it doesn't mention VS 8 and to avoid being outdated soon, it probably should). (BTW VS * Express beta 2 has the feature to set include directories removed by mistake - so you have to edit the xml project file info as a workaround!) And recommending a top level ./boost directory means that one will probably blow the max recommended directory depth for recording onto CDs for backup? And it might be better to recommend a separate partition, say D:? And what about building the libraries with bjam ? Or could we ship the common .lib versions pre-built for MS? The test library is the one most people NEED. Then we would just need to say how to copy to the MS/lib directory. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Flinn | Sent: 25 May 2005 13:47 | To: boost@lists.boost.org | Subject: [boost] Re: Customer Friendlier Boost Installation | | | "Paul A Bristow" <pbristow@hetp.u-net.com> wrote in message | news:E1DarwS-0004uN-KK@he303war.uk.vianw.net... | > Recently we had a flurry of discussion of why Boost is not | more widely | > used. | | ... | | > But if we are to interest your average Windows IDE | programmer, for whom | > MAKE | > is a blank or a distant nightmare, IMO we need some much better and | > simpler | > instructions, including lots of examples of input and | output, and to be as | > well tested as the rest of Boost code. Like it or not, | these are the | > potential customers and I spoken to many who are put off by | the 'build | > barrier'. | > | > I suggest that we explicitly say that you can use all of | Boost (except the | > ones that must have built libraries) by adding to the | include list - and | > say | > exactly how in Windows IDE-ese. | | Something like this as a start? | | For MSVC | ======== | | Organizing boost files | ====================== | | 1) Create a main boost directory which will contain the | current and future | boost library verstions. For example: C:\boost | | 2) Download the desired version(s) of boost (.exe or .zip | files ) from | http://sourceforge.net/project/showfiles.php?group_id=7586&pac | kage_id=8041 | to the boost directory created in step 1. | | 3) Extract the .exe or .zip file(s) from Step 2 into the | directory from Step | 1. These sub-directories should retain the boost version | within it's name. | For example | | C:\boost\boost_1_32_0 | C:\boost\boost_1_31_0 | | Using the header only boost libraries from MSVC7.1 | ================================================== | | Using a single version of boost header only libraries | installation wide | -------------------------------------------------------------- | --------- | | 1) Open an instance of MSVC 7.1 IDE. | | 2) Click the 'Tools | Options...' menu. | | 3) Select the 'Projects | VC++ Directories' item from the | tree view on the | left of the Options dialog. | | 4) Select 'Include Files' from the 'Show directories for' dropdown. | | 5) Double-click just below the last entry in the directory | list box, and | enter the path to the sub-directory for the desired version | of boost. For | example: C:\boost\boost_1_33_0. | | 6) Repeat 5 for each Platform of interest after selecting | another platform | from the 'Platform' dropdown. | | 7) Click Ok. | | | OR | | Using a single version of boost header only libraries on a project by | project basis | -------------------------------------------------------------- | --------------------- | | 1) Open your project with the MSVC 7.1 IDE. | | 2) Select the desired project from the Class View or Solution | View browsers. | | 3) Click the 'Project | Properties' menu. | | 4) Select 'All Configurations' from the 'Configuration' dropdown. | | 5) Select 'Configuration Properties | C/C++ | General' item | from the tree | view on the left of the '<project> Property Pages' dialog. | | 6) Enter the desired boost version directory name in the | 'Additional Include | Directories' value field in the properties listbox. For example: | C:\boost\boost_1_33_0. Note that directories are delimited with ';'. | | 7) Click Ok. | | | Jeff Flinn | | | | _______________________________________________ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/boost |
"Paul A Bristow" <pbristow@hetp.u-net.com> wrote in message news:E1Dax3q-0002Nb-3U@he303war.uk.vianw.net...
Looks very promising for the headers only (though it doesn't mention VS 8 and to avoid being outdated soon, it probably should).
Agreed, but I don't have VS8 here. We still have barely moved from VS6.5 to VS7.1. Finding things between VS6.5 and VS7.1 is very different, I'm not sure how much changes with VS8. I'll have to try out the silly 'Do Not Disturb' card that came in the latest CUJ.
(BTW VS * Express beta 2 has the feature to set include directories removed by mistake - so you have to edit the xml project file info as a workaround!)
And recommending a top level ./boost directory means that one will probably blow the max recommended directory depth for recording onto CDs for backup?
I haven't had that problem, since I copy the latest boost version from my harddrive to a network drive once I've built the libraries. The net drive is used by our build system, and backed up by out sys admin. I've never heard complaints there.
And it might be better to recommend a separate partition, say D:?
Why so? I've got the last 5 versions of boost existing on my system with no problem. Seems that a recommendation like that could end up scaring potential users.
And what about building the libraries with bjam ?
Sorry, I was responding to your specific request: "I suggest that we explicitly say that you can use all of Boost (except the ones that must have built libraries) by adding to the include list - and say exactly how in Windows IDE-ese."
Or could we ship the common .lib versions pre-built for MS? The test library is the one most people NEED.
I'm not sure of the utility if the intent is to allow users access to header-only libraries so that they don't have to use bjam to do any building.
Then we would just need to say how to copy to the MS/lib directory.
My stage directory for boost_1_32_0 is 570MB, which includes all debug/release variants for VC7.1(excluding python). Even with compression this could still be a quite large download. Jeff Flinn
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
Something like this as a start?
For MSVC ========
Organizing boost files ======================
1) Create a main boost directory which will contain the current and future boost library verstions. For example: C:\boost
Maybe not such a good choice considering that it's the default install location for Windows? Or should we change the default (and if so, to what?)
2) Download the desired version(s) of boost (.exe or .zip files ) from http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041 to the boost directory created in step 1.
3) Extract the .exe or .zip file(s) from Step 2 into the directory from Step 1. These sub-directories should retain the boost version within it's name. For example
C:\boost\boost_1_32_0 C:\boost\boost_1_31_0
Using the header only boost libraries from MSVC7.1 ==================================================
Using a single version of boost header only libraries installation wide -----------------------------------------------------------------------
1) Open an instance of MSVC 7.1 IDE.
2) Click the 'Tools | Options...' menu.
3) Select the 'Projects | VC++ Directories' item from the tree view on the left of the Options dialog.
4) Select 'Include Files' from the 'Show directories for' dropdown.
5) Double-click just below the last entry in the directory list box, and enter the path to the sub-directory for the desired version of boost. For example: C:\boost\boost_1_33_0.
6) Repeat 5 for each Platform of interest after selecting another platform from the 'Platform' dropdown.
7) Click Ok.
OR
Using a single version of boost header only libraries on a project by project basis -----------------------------------------------------------------------------------
1) Open your project with the MSVC 7.1 IDE.
2) Select the desired project from the Class View or Solution View browsers.
3) Click the 'Project | Properties' menu.
4) Select 'All Configurations' from the 'Configuration' dropdown.
5) Select 'Configuration Properties | C/C++ | General' item from the tree view on the left of the '<project> Property Pages' dialog.
6) Enter the desired boost version directory name in the 'Additional Include Directories' value field in the properties listbox. For example: C:\boost\boost_1_33_0. Note that directories are delimited with ';'.
7) Click Ok.
Jeff Flinn
Cool! Would you like CVS access so you can enhance the docs? Send me your SourceForge username, if so. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uzmui3mya.fsf@boost-consulting.com...
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
Something like this as a start?
For MSVC ========
Organizing boost files ======================
1) Create a main boost directory which will contain the current and future boost library verstions. For example: C:\boost
Maybe not such a good choice considering that it's the default install location for Windows? Or should we change the default (and if so, to what?)
Sorry, "location for Windows" has too many overloads for me to know what your asking here. What exactly is the problem using C:\boost? ...
Cool! Would you like CVS access so you can enhance the docs? Send me your SourceForge username, if so.
Ok, I'm a real neophyte here though. I assume somehow that I need to get a SF user name. Any hints on doing that? Does this mean I subscribe to sourceforge? Thanks, Jeff Flinn
On 5/26/05, Jeff Flinn <TriumphSprint2000@hotmail.com> wrote:
Sorry, "location for Windows" has too many overloads for me to know what your asking here. What exactly is the problem using C:\boost?
Because when you do a "bjam install" on Windows, thats the default directory where the header files and libraries are placed. It would be a bad idea to use the same directory for the source code and the installation. I think that if the standard Windows source code distribution (say a self-extracting Zip file) should extract to boost_<version>. I think this is alreayd the case. Then we can suggest to folks that they just extract this in C:\ -- Caleb Epstein caleb dot epstein at gmail dot com
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uzmui3mya.fsf@boost-consulting.com...
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
Something like this as a start?
For MSVC ========
Organizing boost files ======================
1) Create a main boost directory which will contain the current and future boost library verstions. For example: C:\boost
Maybe not such a good choice considering that it's the default install location for Windows? Or should we change the default (and if so, to what?)
Sorry, "location for Windows" has too many overloads for me to know what your asking here. What exactly is the problem using C:\boost?
Right now if you say bjam whatever install on windows, the result is installed to c:\boost. I'm not sure it makes a good overlap. Of course, I've never done it myself, so I don't know what ends up in c:\boost if you install or what the difference between install and stage are. Rene?
Cool! Would you like CVS access so you can enhance the docs? Send me your SourceForge username, if so.
Ok, I'm a real neophyte here though. I assume somehow that I need to get a SF user name. Any hints on doing that? Does this mean I subscribe to sourceforge?
Yes, go to www.sf.net and follow the directions. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Jeff Flinn" <TriumphSprint2000@hotmail.com> writes:
Sorry, "location for Windows" has too many overloads for me to know what your asking here. What exactly is the problem using C:\boost?
Right now if you say
bjam whatever install
on windows, the result is installed to c:\boost. I'm not sure it makes a good overlap.
Of course, I've never done it myself, so I don't know what ends up in c:\boost if you install or what the difference between install and stage are. Rene?
"install".. C:\Boost\.. ..\lib\lib*.lib ..\lib\*.lib ..\lib\*.dll ..\include\boost-1_32_0\boost\* "stage".. [current-dir]\.. ..\stage\lib\lib*.lib ..\stage\lib\*.lib ..\stage\lib\*.dll -- -- 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
Rene Rivera <grafik.list@redshift-software.com> writes:
Of course, I've never done it myself, so I don't know what ends up in c:\boost if you install or what the difference between install and stage are. Rene?
"install"..
C:\Boost\.. ..\lib\lib*.lib ..\lib\*.lib ..\lib\*.dll ..\include\boost-1_32_0\boost\*
"stage"..
[current-dir]\.. ..\stage\lib\lib*.lib ..\stage\lib\*.lib ..\stage\lib\*.dll
Well, I think we need to find a way to spell that out in the Getting Started guide. And I suggest you use real elipses rather than ".." because I'm *certain* you don't mean "parent directory!" -- Dave Abrahams Boost Consulting www.boost-consulting.com
[...]
on windows, the result is installed to c:\boost. I'm not sure it makes a good overlap.
IMHO c:\boost is a very bad choice! Creating driectories directly in the root is never nice, not even on Windows! Why not $PROGRAM_FILES$\boost\ or even better $PROGRAM_FILES$\boost\$VERSION$\ where $VERSION$ is the version of boost and $PROGRAM_FILES$ is what ever path your system tells you when asked with the right Win32 API call? (On my german system that would be C:\Programme) Even for libraries this is IMHO the only "right" location to install too per default. Bertolt
Bertolt Mildner wrote:
$PROGRAM_FILES$ is what ever path your system tells you when asked with the right Win32 API call? (On my german system that would be C:\Programme)
Unfortunately, this will mean "C:\Program Files" by default on English systems; paths with spaces should IMHO definitely be avoided. Other localized versions of Windows may have a similar problem.
Even for libraries this is IMHO the only "right" location to install too per default.
Disagree. %PROGRAMFILES% is intended for program files. There is no "correct" location for development files on Windows. Myself, I have a "C:\src" directory where all development takes place. (I agree with you otherwise: Littering the root with directories is Not Nice.)
Bertolt
-- /Brian Riis
Bertolt Mildner wrote:
$PROGRAM_FILES$ is what ever path your system tells you when asked with
"Brian Ravnsgaard Riis" <brian@riis.as> schrieb im Newsbeitrag news:42982654.4060306@riis.as... the
right Win32 API call? (On my german system that would be C:\Programme)
Unfortunately, this will mean "C:\Program Files" by default on English systems; paths with spaces should IMHO definitely be avoided. Other localized versions of Windows may have a similar problem.
yes, spaces used to make problems, but that should have gone!? Which (widely used) tools on Win32 still have problems with spaces?
Even for libraries this is IMHO the only "right" location to install too per default.
Disagree. %PROGRAMFILES% is intended for program files. There is no "correct" location for development files on Windows. Myself, I have a "C:\src" directory where all development takes place. (I agree with you otherwise: Littering the root with directories is Not Nice.)
As there is no common place for libraries (incl. header, static link libs) the next best IMHO thing is %PROGRAMFILES%. What options do we have: - new dir in root: Not a option, imagine everyone would do that! - system directory (\Windows, \WinNT, ...): That's a BIG NO-NO! - "documents and settings" (\Dokumente und Einstellungen in german): Settings does not fit, documents could fit somehow but typically only documents one creates himself should go there. - %PROGRAMFILES%: That is all what is left, and it is the typical place to install to! Bertolt
Bertolt Mildner a écrit :
What options do we have: [...] - %PROGRAMFILES%: That is all what is left, and it is the typical place to install to! This is where Microsoft installs its SDK.
Another few solutions (probably not good, but just here for completness...) - %VSINSTALLDIR% - \lib\boost: This one is not much different from \boost, but if some other people start to do the same... -- Loïc
Bertolt Mildner wrote:
yes, spaces used to make problems, but that should have gone!?
Which (widely used) tools on Win32 still have problems with spaces?
All the GNU tools. Which means a MinGW installation as well. I agree it sucks, but...
Disagree. %PROGRAMFILES% is intended for program files. There is no "correct" location for development files on Windows. Myself, I have a "C:\src" directory where all development takes place. (I agree with you otherwise: Littering the root with directories is Not Nice.)
As there is no common place for libraries (incl. header, static link libs) the next best IMHO thing is %PROGRAMFILES%.
What options do we have:
- new dir in root: Not a option, imagine everyone would do that!
Isn't it? C:\Lib\boost\... C:\Lib\wxwidgets\... ... Of course, this assumes that everyone will "play nice" and actually use C:\Lib\ as starting point. This would definitely be my choice, though.
- system directory (\Windows, \WinNT, ...): That's a BIG NO-NO!
A VERY big no-no!
- "documents and settings" (\Dokumente und Einstellungen in german): Settings does not fit, documents could fit somehow but typically only documents one creates himself should go there.
Actually, I was wondering about C:\Documents and Settings\<user>\Application Data\... But then we have the issue with the spaces again.
- %PROGRAMFILES%: That is all what is left, and it is the typical place to install to!
I'm not really opposed to it, if everyone agrees on it. Using %PROGRAMFILES% for it just sorta rubs me the wrong way. But, as mentioned, there's no "right" location, so...
Bertolt
-- /Brian Riis
Brian Ravnsgaard Riis wrote:
Bertolt Mildner wrote:
As there is no common place for libraries (incl. header, static link libs) the next best IMHO thing is %PROGRAMFILES%.
Well, even Microsoft isn't sure what location to use. DDK installes to root, and Platform SDK to Program files. So I think boost should introduce such a location and suggest other libraries to select this installation location too.
What options do we have:
- new dir in root: Not a option, imagine everyone would do that!
Isn't it?
I agree. Now boost is a bad example for other libraries. If all libraries will follow boost's example, we would get c:\boost, c:\zlib, c:\cppunit, c:\mpich2 etc. This is definitely a bad idea.
C:\Lib\boost\... C:\Lib\wxwidgets\... ...
Of course, this assumes that everyone will "play nice" and actually use C:\Lib\ as starting point. This would definitely be my choice, though.
I would suggest just %SystemDrive%\lib: users will have to /I %SystemDrive%\lib\boost_1_33 and add %SystemDrive%\lib\ to their source paths. Includes for other libraries should go to %SystemDrive%\lib\zlib_1_2_1 and libraries for other libraries should go to \lib\lib along with boost. I really like boost library file naming convention, and it would be nice if other libraries would move to this convention and folder layout. Anderei
Andrey Melnikov <melnikov@simplexsoft.com> writes:
Brian Ravnsgaard Riis wrote:
Bertolt Mildner wrote:
As there is no common place for libraries (incl. header, static link libs) the next best IMHO thing is %PROGRAMFILES%.
Well, even Microsoft isn't sure what location to use. DDK installes to root, and Platform SDK to Program files. So I think boost should introduce such a location and suggest other libraries to select this installation location too.
What options do we have:
- new dir in root: Not a option, imagine everyone would do that!
Isn't it?
I agree.
Now boost is a bad example for other libraries. If all libraries will follow boost's example, we would get c:\boost, c:\zlib, c:\cppunit, c:\mpich2 etc. This is definitely a bad idea.
Sheesh, I don't see what the big deal is. It's not like you can't put it wherever you like, whenever you like: as part of installation, or later. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
Now boost is a bad example for other libraries. If all libraries will follow boost's example, we would get c:\boost, c:\zlib, c:\cppunit, c:\mpich2 etc. This is definitely a bad idea.
Sheesh, I don't see what the big deal is. It's not like you can't put it wherever you like, whenever you like: as part of installation, or later.
We should consider that users are used to think that installation isn't just a copy, and they are afraid to relocate 'installed' files. Why having installation feature at all then? Let's make stage copying headers to stage\ too, and let users decide where to actually copy the files. I don't see any reasons why to have default installation location which most users hate? There are basically two opinions in this thread: - I hate c:\boost location - Installation location doesn't really matters because I don't use install/I relocate files myself/I don't bother about structural look of my drives. Current location suits no one. \libs\boost or %ProgramFiles%\boost will make at least *some* users comfortable. Andrei
Andrey Melnikov wrote:
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
Now boost is a bad example for other libraries. If all libraries will follow boost's example, we would get c:\boost, c:\zlib, c:\cppunit, c:\mpich2 etc. This is definitely a bad idea.
Sheesh, I don't see what the big deal is. It's not like you can't put it wherever you like, whenever you like: as part of installation, or later.
We should consider that users are used to think that installation isn't just a copy, and they are afraid to relocate 'installed' files.
Whats the problem? The installer just has a default location and as standard in installers you get to see this and the option to change it *before* installation. It just doesn't really seem to matter what the default location is. (FWIW I dont think Program Files is the right place as default but there ya go). Martin. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 27/05/2005
Martin Slater <mslater@hellinc.net> wrote:
[...]
We should consider that users are used to think that installation isn't just a copy, and they are afraid to relocate 'installed' files.
Whats the problem? [...]
Users are used to think that installation isn't just a copy.
Martin.
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
Users are used to think that installation isn't just a copy.
Theres no need for them to copy it, they just choose an appropriate installation directory for them. If they have installed it in the wrong place (for them) they either copy or if scared to do so uninstall and reinstall in the correct location. Still see no problem. Martin -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 27/05/2005
Martin Slater <mslater@hellinc.net> wrote:
[...] Theres no need for them to copy it, they just choose an appropriate installation directory for them. If they have installed it in the wrong place (for them) they either copy or if scared to do so uninstall and reinstall in the correct location. Still see no problem.
When I did the quick test, I did the wrong thing to prevent bjam from using "C:\Boost". Meanwhile I've seen how I could do this, but I think this whole thread was started to make it easier for novices to check out boost. Having to learn a special tool (bjam) in order to do that isn't exactly easy (even if the expected usage might be rather trivial).
Martin
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
but I think this whole thread was started to make it easier for novices to check out boost. Having to learn a special tool (bjam) in order to do that isn't exactly easy (even if the expected usage might be rather trivial).
Exactly and it doesn't matter where you run bjam from or not its no different. The easiest thing to do is to hide from the user the fact bjam is running by a simple gui run post installation (this installs boost source tree and prebuit bjam binaries into the install directory and adds the directory to the user path) that allows common configurations to be built at the touch of a button as well as adding the install include + lib directories to the toolsets include + lib paths if they support that. This is a very simple first step in usability without going the whole hog of auto generating solution files and whatnot from the bjam build source. I wouldnt imagine this would take more than a day to put together (at least in demo form) and may well help guide the discussion. Martin -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 27/05/2005
Andrey Melnikov <melnikov@simplexsoft.com> writes:
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
Now boost is a bad example for other libraries. If all libraries will follow boost's example, we would get c:\boost, c:\zlib, c:\cppunit, c:\mpich2 etc. This is definitely a bad idea. Sheesh, I don't see what the big deal is. It's not like you can't put it wherever you like, whenever you like: as part of installation, or later.
We should consider that users are used to think that installation isn't just a copy, and they are afraid to relocate 'installed' files.
Why having installation feature at all then? Let's make stage copying headers to stage\ too, and let users decide where to actually copy the files.
I don't see any reasons why to have default installation location which most users hate? There are basically two opinions in this thread: - I hate c:\boost location - Installation location doesn't really matters because I don't use install/I relocate files myself/I don't bother about structural look of my drives.
Current location suits no one.
I'm not convinced of that. I don't think it's particularly good, but I'm sure it's fine for a few people. *Lots* of people install Python in its default location on Windows: C:\Python24. As far as I can tell, there are no complaints. Google around to see if you can find any.
\libs\boost or %ProgramFiles%\boost will make at least *some* users comfortable.
The question is, will it make *more* people comfortable? I prefer not to change anything until we have an alternative that's definitively an improvement. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
\libs\boost or %ProgramFiles%\boost will make at least *some* users comfortable.
The question is, will it make *more* people comfortable?
Program Files requires administrative or Power User rights and is reserved for (gasp) program files, but \libs\boost doesn't sound bad.
Peter Dimov wrote:
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
\libs\boost or %ProgramFiles%\boost will make at least *some* users comfortable.
The question is, will it make *more* people comfortable?
Program Files requires administrative or Power User rights and is reserved for (gasp) program files, but \libs\boost doesn't sound bad.
\libs\boost sounds reasonable. I agree, as well, with the arguments against using Program Files. Jeff Flinn
Jeff Flinn wrote:
Peter Dimov wrote:
David Abrahams wrote:
Andrey Melnikov <melnikov@simplexsoft.com> writes:
\libs\boost or %ProgramFiles%\boost will make at least *some* users comfortable.
The question is, will it make *more* people comfortable?
Program Files requires administrative or Power User rights and is reserved for (gasp) program files, but \libs\boost doesn't sound bad.
\libs\boost sounds reasonable.
I agree, as well, with the arguments against using Program Files.
I'm not sure "libs", or "Libraries", or "Library Files", fits in this case because we are talking about both programs(bjam, wave, etc.) and libraries. And the other examples, Python, MinGW, etc. also install programs. A more appropriate location would be: "\Development Files\Boost" "\Development Files\Python" "\Development Files\MinGW" ... Although the shorter "\Development\*" would probably works as well. But if we are talking about such a location you need to consider language localization, in the same way as "Program Files" treated. -- -- 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
Rene Rivera <grafik.list@redshift-software.com> wrote:
[...] Although the shorter "\Development\*" would probably works as well. But if we are talking about such a location you need to consider language localization, in the same way as "Program Files" treated.
I don't think so. Noone has a chance to use boost if they don't read English. All the identifiers are in English, all the comments are in English, all the docs are in English, the website is in English, almost all places were one could get support are in English... Doing C++ programming without at least some basic understanding of English is nigh impossible, doing professional C++ programming without it really is impossible. FWIW, noone at my job (Berlin, Germany) says "Bibliothek", everyone says "Library". In fact, the German word has a very odd sound when applied to programming libs, indicating that I rarely heard it anywhere at all. Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
Rene Rivera wrote:
Jeff Flinn wrote:
I'm not sure "libs", or "Libraries", or "Library Files", fits in this case because we are talking about both programs(bjam, wave, etc.) and libraries. And the other examples, Python, MinGW, etc. also install programs. A more appropriate location would be:
"\Development Files\Boost" "\Development Files\Python" "\Development Files\MinGW" ...
Although the shorter "\Development\*" would probably works as well. But if we are talking about such a location you need to consider language localization, in the same way as "Program Files" treated.
Just two more agruments for %ProgramFiles%: On Windows %ProgramFiles% is more like %Packages%. Anything what is installed usually goes there. Even non-programs like MSDN or Platform SDK. And root has the same access permissions like %ProgramFiles%, hasn't it? On security-restricted machine the only place which is always write-enabled is %USERPROFILE%/%HOME%. I agree with rest arguments against ProgramFiles, but I think that ProgramFiles and \libs are equally better than c:\ I wonder, if it's hardcoded c:, or %SystemDrive%? Andrey
Rene Rivera wrote:
I'm not sure "libs", or "Libraries", or "Library Files", fits in this case because we are talking about both programs(bjam, wave, etc.) and libraries. And the other examples, Python, MinGW, etc. also install programs. A more appropriate location would be:
"\Development Files\Boost" "\Development Files\Python" "\Development Files\MinGW" ...
Although the shorter "\Development\*" would probably works as well. But if we are talking about such a location you need to consider language localization, in the same way as "Program Files" treated.
Personally I have \Packages\boost ... For my development related stuff such as libraries, scripting languages (python, ruby, perl), cygwin et al. /Michel
From: =?UTF-8?B?TWljaGVsIEFuZHLDqQ==?= <michel.andre@swipnet.se>
Rene Rivera wrote:
I'm not sure "libs", or "Libraries", or "Library Files", fits in this case because we are talking about both programs(bjam, wave, etc.) and libraries. And the other examples, Python, MinGW, etc. also install programs. A more appropriate location would be:
"\Development Files\Boost" "\Development Files\Python" "\Development Files\MinGW" ...
Although the shorter "\Development\*" would probably works as well. But if we are talking about such a location you need to consider language localization, in the same way as "Program Files" treated.
Personally I have \Packages\boost
I always use <drive>:\dev or $HOME/dev, depending upon platform. "dev" is short and sweet. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
From: =?UTF-8?B?TWljaGVsIEFuZHLDqQ==?= <michel.andre@swipnet.se>
Rene Rivera wrote:
I'm not sure "libs", or "Libraries", or "Library Files", fits in this case because we are talking about both programs(bjam, wave, etc.) and libraries. And the other examples, Python, MinGW, etc. also install programs. A more appropriate location would be:
"\Development Files\Boost" "\Development Files\Python" "\Development Files\MinGW" ...
Although the shorter "\Development\*" would probably works as well. But if we are talking about such a location you need to consider language localization, in the same way as "Program Files" treated.
Personally I have \Packages\boost
I always use <drive>:\dev or $HOME/dev, depending upon platform. "dev" is short and sweet.
Regardless, it's clear from all these opinions that there's no "right answer." -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Rob Stewart <stewart@sig.com> writes:
From: =?UTF-8?B?TWljaGVsIEFuZHLDqQ==?= <michel.andre@swipnet.se>
Rene Rivera wrote:
I'm not sure "libs", or "Libraries", or "Library Files", fits in this case because we are talking about both programs(bjam, wave, etc.) and libraries. And the other examples, Python, MinGW, etc. also install programs. A more appropriate location would be:
"\Development Files\Boost" "\Development Files\Python" "\Development Files\MinGW" ...
Although the shorter "\Development\*" would probably works as well. But if we are talking about such a location you need to consider language localization, in the same way as "Program Files" treated.
Personally I have \Packages\boost
I always use <drive>:\dev or $HOME/dev, depending upon platform. "dev" is short and sweet.
Regardless, it's clear from all these opinions that there's no "right answer."
Yes. I agree that at the moment there are no right place. But it's also clear that nobody uses root (or very few people). Everybody uses <drive>:\%something%\boost, so \dev\boost, \libs\boost or \program files\boost seems to be a bit more reasonable than just \boost. I vote for \dev - it's short and satisfies both tools like bjam and libraries.. Or maybe \dev\libs :) Andrey
Andrey Melnikov <melnikov@simplexsoft.com> writes:
David Abrahams wrote:
Rob Stewart <stewart@sig.com> writes:
From: =?UTF-8?B?TWljaGVsIEFuZHLDqQ==?= <michel.andre@swipnet.se>
Rene Rivera wrote:
I'm not sure "libs", or "Libraries", or "Library Files", fits in this case because we are talking about both programs(bjam, wave, etc.) and libraries. And the other examples, Python, MinGW, etc. also install programs. A more appropriate location would be:
"\Development Files\Boost" "\Development Files\Python" "\Development Files\MinGW" ...
Although the shorter "\Development\*" would probably works as well. But if we are talking about such a location you need to consider language localization, in the same way as "Program Files" treated.
Personally I have \Packages\boost
I always use <drive>:\dev or $HOME/dev, depending upon platform. "dev" is short and sweet. Regardless, it's clear from all these opinions that there's no "right answer."
Yes. I agree that at the moment there are no right place. But it's also clear that nobody uses root (or very few people).
Count me among the few. Boost is so important to me that the CVS lives at c:\boost.
Everybody uses <drive>:\%something%\boost, so \dev\boost, \libs\boost or \program files\boost seems to be a bit more reasonable than just \boost. I vote for \dev - it's short and satisfies both tools like bjam and libraries.. Or maybe \dev\libs :)
I have no serious objections, but would like to have more confidence that it's going to be a real improvement. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Bertolt Mildner" <Bertolt.Mildner@gmx.at> writes:
[...]
on windows, the result is installed to c:\boost. I'm not sure it makes a good overlap.
IMHO c:\boost is a very bad choice! Creating driectories directly in the root is never nice, not even on Windows!
Why not $PROGRAM_FILES$\boost\ or even better $PROGRAM_FILES$\boost\$VERSION$\
Well, because Boost is not a Program File (application).
where
$VERSION$ is the version of boost and
$PROGRAM_FILES$ is what ever path your system tells you when asked with the right Win32 API call? (On my german system that would be C:\Programme)
Even for libraries this is IMHO the only "right" location to install too per default.
What's the precedent? Python installs to c:\PythonXX where XX is a version number * 10. FWIW. At least if it's installed to C:\boost you can find it easily and move it wherever you like. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Note: I am keenly interested in making Boost installation better. I have a lot of honest questions below, but they are not meant to be challenges. In order to make things better, we need the answers. "Paul A Bristow" <pbristow@hetp.u-net.com> writes:
Recently we had a flurry of discussion of why Boost is not more widely used.
I have used some bits of Boost happily for years, but recently I felt I had to use it 'properly' so concluded it was time I used the bjam build system - something I had felt looked a bit clever.
Indeed my suspicion was proved correct - I couldn't get it to work.
Where did you get stopped? What was the problem?
The instructions
I assume you mean http://www.boost.org/more/getting_started.html?
are far too Unix/Make oriented for this mere Windows hacker;
In what way are they Unix/Make oriented?
the Wiki Windows specific instructions are much better
In what way are they better?
but suggest copying (duplicating) a lot of files to avoid an addition to the include directories, and don't apply to the most recent compilers.
Two points "against." What are the points "for?"
Victor Wagner gave some hints recently using environment variables, but not the full text.
I don't doubt the usefulness of the bjam to the congescenti - only with this could the incredibly impressive build & test system allow all the cracks and chasms of compiler non-compliance and language imprecision to be papered over - Boost's great strength.
But if we are to interest your average Windows IDE programmer, for whom MAKE is a blank or a distant nightmare, IMO we need some much better and simpler instructions,
I think we need a Windows installer. 90% of C++ programmers use VC++ (sometimes along with others), so it's worth special-casing this one.
including lots of examples of input and output,
I can't imagine how adding lots of examples could make the instructions for installing Boost any better. Can you propose some examples? Maybe you are talking about instructions for using Boost.Build in general, as opposed to instructions for "installing Boost"? If so, I agree. Boost.Build version 2, which is not yet the official one we use for testing, should be easier to use and better documented than version 1. That said, the documentation needs a lot of work. Several months ago I spent 2 weeks going through it all and putting editorial comments in every place it was unclear, which was many. Vladimir Prus, the author of the current docs, started going through my remarks and making fixes, but he only got halfway done, and hasn't yet made any of the overall structural changes AFAICT. So we could really use some help on the documentation, especially from someone who has credibility as a total novice with Boost.Build.
and to be as well tested as the rest of Boost code.
http://www.boost.org/more/getting_started.html has been pretty darned well tested.
Like it or not, these are the potential customers and I spoken to many who are put off by the 'build barrier'.
I agree.
I suggest that we explicitly say that you can use all of Boost (except the ones that must have built libraries) by adding to the include list - and say exactly how in Windows IDE-ese.
Sure, that's a good idea.
If you share my concern, would some someone like to prepare something?
If you mean prepare the advice that "you can use all of Boost (except the ones that must have built libraries) by adding to the include list - and say exactly how in Windows IDE-ese," I think you're the perfect man for the job. If you mean something else, then what?
Or at least provide details of their way of doing it.
It would help a lot if you'd specify more carefully what "it" is. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
[...] "Paul A Bristow" <pbristow@hetp.u-net.com> writes: [...]
the Wiki Windows specific instructions are much better
Oh, I didn't think of looking at the wiki. Is there more than in the "official" docs?
In what way are they better? [...]
Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "Coming back to where you started is not the same as never leaving" Terry Pratchett
Paul A Bristow a écrit :
Recently we had a flurry of discussion of why Boost is not more widely used.
I have used some bits of Boost happily for years, but recently I felt I had to use it 'properly' so concluded it was time I used the bjam build system - something I had felt looked a bit clever.
First of all : a disclaimer: I just skimmed through the whole discussion, so the points in my posts might be adressed somewhere else. I basically agree with this opinion, since it has also been a remark people make to me about boost (I'm the main boost proponent in my office). So here is my proposal: * First, easy to do, include more examples in the documentation. I've verified several times that when they don't want to read and understand a whole document, people try to skip to the examples. Just something like : To build all with VC++7.1 : (after calling the correct VCVARS.bat) bjam "-sTOOLS=vc-7_1" install To build only the serialization module with VC++6.0 : bjam "-sTOOLS=msvc" --with-serialization install To build only the multithread version vith BC++ bjam "-sTOOLS=borland" "-sBUILD=<threading>multi" install // I'm really not sure for this one * Second, provide a compiled bjam for major platforms directly in the distribution (ok, the distribution will be bigger. Is this a problem ?) * Third, provide some script to add boost to the compiler path (I do not know how to do this...) * Finally, installing boost takes longer than installing VC++... Is building from the source such an important point ? Would'nt it be possible to provide pre-built libraries for the 3 or 4 main compilers on windows with each release ? The whole package, zipped, is 80mb on my VC8. -- Loïc
Loïc Joly wrote:
To build all with VC++7.1 : (after calling the correct VCVARS.bat) bjam "-sTOOLS=vc-7_1" install
To build only the serialization module with VC++6.0 : bjam "-sTOOLS=msvc" --with-serialization install
To build only the multithread version vith BC++ bjam "-sTOOLS=borland" "-sBUILD=<threading>multi" install // I'm really not sure for this one
* Second, provide a compiled bjam for major platforms directly in the distribution (ok, the distribution will be bigger. Is this a problem ?)
We can just do the following: -------------------------------- To build all with VC++7.1: build-bjam.bat <- to be created and placed at root bjam "-sTOOLS=vc-7_1" install -------------------------------- Specifying correct vcvars isn't nesessary any more. I remember I had this problem with 1.31, but 1.33 calls correct vcvars itself. As I suggested in another thread, we can also create files like vc-2003-default-build.bat. This will eliminate nasty typing at all. Also I know a lot of people which always choose "full install", so these ones will be completely happy. Andrei
participants (33)
-
Andrey Melnikov -
Beman Dawes -
Bertolt Mildner -
Bjørn Roald -
Brian Ravnsgaard Riis -
Caleb Epstein -
David Abrahams -
David Bergman -
Fabio Fracassi -
Hendrik Schober -
Hendrik Schober -
Jason Earl -
Jeff Flinn -
Jody Hagins -
Jonathan Wakely -
larsbj＠gullik.net -
Loïc Joly -
Manfred Doudar -
Martin Slater -
Michel André -
Nevin Liber -
Oliver Kullmann -
Paul A Bristow -
Peter -
Peter Dimov -
Reece Dunn -
Rene Rivera -
Rob Stewart -
Robert Mathews -
Russell Hind -
Shishir Ramam -
Stuart Dootson -
Victor A. Wagner Jr.