Re: Newbee: Build/Installation Questions

6 Jun 2003


      Adalbert Perbandt  writes:
...
...
...
...
...
...
"David" == David Abrahams  writes:
David> Adalbert Perbandt  writes:
    >> To get the header files installed I ran
    >> 
    >> $ bjam -sTOOLS=sunpro -sBUILD=install
David> Nope.  "install" is not a build variant.
Hmm, seems to me if I misunderstood something. I found a set of so
called "Pseudotargets: described in the
tools/build/jam_src/Jambase.html page.
We should probably get rid of that; it only applies to "Classic Jam",
not Boost.Build.  But anyway, pseudotargets are not the same as build
variants.
...
In between I followed your hint in a reply to another question and
specified the installation directory like this:
$ bjam -sTOOLS=sunpro -sALL_LOCATE_TARGET=<installDir>
[...]
    David> Nope.  Being able to isolate header dependencies and
    David> separate them from the rest of Boost is not a feature we
    David> have implemented.  Boost is meant to be installed "en
    David> masse"
O.k. So I simply copy the whole directory tree including and below the
"boost" directory into my installation dir and configure the compiler
with -I.
Yep.
...
I wonder why the installation directory-hierarchy is that
complex. Each one of the libs. is stored under a seprate directory:
<installDir>/
  libs/
    test/
      build/
        bin/
          <libName>/
            sunpro/
              debug|release/
                runtime-link-dynamic/
                  <libFile>
That's not the installation directory hierarchy, it's the build
directory hierarchy.  We don't have a formal intallation process; the
closest we have are stage targets which typically get built into
less-deep directories.  The reason for the long paths is to isolate
different link-incompatible variants that you might build of a
library.  The Boost.Build system is doing that for developers more
than for installers.  The user-expected-installation-behavior problem
is one we have yet to solve well.
...
If I want to use more than one lib I have to specify multiple lengthy -L
options for the link command pointing to each of the required
libraries's directories.
Just copy the library to a less-onerous place then.
...
What is the rational behind this directory structure?
See above.
...
I would find it more convenient if I had all the libs that were build
the same way (same compiler, same compile mode [debug/release] stored
together in one directory.
I'm sure.  We'd appreciate your participation in the Boost.Build v2
project.  See http://www.boost.org/more/mailing_lists.htm to get on
the mailing list.
...
What does this directory "runtime-link-dynamic/" mean?
It means that the library is built to link with the shared runtime as
opposed to the static one.
...
Sorry if these are stupid questions. I'm not that experienced yet with
using C++ libraries (except the STL) in my projects.
No problem; they're not stupid.

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