Re: Newbee: Build/Installation Questions

From: David Abrahams (dave_at_[hidden])
Date: 2003-06-06 06:42:36

Adalbert Perbandt <adalbert.perbandt_at_[hidden]> writes:

>>>>>> "David" == David Abrahams <dave_at_[hidden]> writes:
>
>     David> Adalbert Perbandt <adalbert.perbandt_at_[hidden]> 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<install_path>. 

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