I'm having problems figure out what the "Build and Install" section on http://www.boost.org/more/getting_started.html means.
This has always been very confusing to me. In the past I've just horsed around until it started to worked and then went on with what I was trying to do. Now I'm augmenting the jam files for serialization build and testing and want to get this right.
I read this section and the following questions come to mind:
4) "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."
This sounds like it means it creates for me a whole new directory
structure with all the boost includes all over again. In fact that
what I think it does.
That's exactly what it means. It does "copy" headers and built libraries to the install location. The process of installation invariably means to copy from one place to another.
When I first read this it makes no sense to me as I would never occur to me why anyone would want to do this since its just a copy of what I just downloaded and unzipped.
It's sometimes hard to think like other people ;-) But in his case we have gotten feedback from those other people saying this is something they want. Also two things are possible once you can install. One, you can delete the thing you downloaded and unzipped, and any build by-products right after installation, saving you space. Two, it allows other people to create other forms of distributions that may not require you to download and unzip all of Boost, i.e. RPMs, DEBs, etc.
One thing I seem to get with the default is a ./bin/boost/... directory with a deep hierarchy with all the libraries. This is something I would never expect from reading the above.
And that is intentional. There's no point in mentioning the intermediate files created to perform the build. Do you really care that, for example, when build+installing GCC you get three copies of the compiler, only one of which is installed/copied to /usr/local? (gcc is only a domain relevant example, replace any other *nix program for the same effect)
5) "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 " again I'm mystified why anyone would want to do what I think this does.
"Or if you are interested only in the built libraries you can have
them built and collected to a common directory without installation. bjam "-sTOOLS=gcc" stage "
This seems more in line with what I would expect most people would want.
You always have to ask yourself who "most people" are. My definition for this context are those people who are interested *only* in using the Boost libraries. Those people are not interested in looking at the source code, and if given the option would look only at the documentation (either online, as a single Boost book, or somehow installed)
The terms install, and stage, though defined (sort of) are confusing to me.
That has been pointed out before ;-) And when someone comes up with a better name for "stage" it's staying as is.
--libdir= --stagedir=
Now I'm confused about the difference between the lib directory and
stage directory.
If you are familiar with "configure" type build+installs --libdir should be apparent.
I sort of surmise that the he lib directory is the root of the deep tree that has branches for all the different variants. But that's not clear to me.
It's not. "lib" is the directory where it _installs_ the built libraries (*.so, *.a, *.dll, *.lib). For example a common place on Linux would be /usr/local/lib.
"Results"
"The results of building come in to forms: .." "to" should be speed
"two"
Oops :-) I though I had fixed that.
I think the 1_31 should be changed to 1_32
Also been covered before.. If we went around changing occurances of version numbers used as example it would consume a lot of time updating documentation for no real gain.
"Automatic Linking on Windows"
Only comment on this, since I didn't write that part, is that this is a "getting started" document, not a "build, install, and use comprehensive reference for Boost and all compilers".
I would also like to a section called
"Testing your installation"
Given the, to me and what is currently done, usual meaning of install, testing the installation would need to be very different than just running the regression tests. It would involve checking that the files all got copied correctly, and running a set of compilations to test that linking to the libraries works.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Boost-docs mailing list
[EMAIL PROTECTED]
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs
