Re: [Boost-users] Re: Are BOOST_BUILD_PATH && BOOST_ROOT necessary?

From: Steven T. Hatton (hattons_at_[hidden])
Date: 2004-09-05 18:34:55

On Saturday 04 September 2004 22:56, Rene Rivera wrote:
> David Abrahams wrote:
> > "Steven T. Hatton" <hattons_at_[hidden]> writes:
...

> Installing to /usr/local/lib was the most requested location by users.
> The majority of users did *not* want to modify the standard search
> location variables or call ldconfig (or whatever the equivalent is for
> each platform).

usr/local/lib is not an uncommon default.  I typically install virtually all 
my (dozens of) development libraries in my own user space, and add them to my 
user environment variables.  My systems administrator - who has well over a 
decade of solid experience - does not let me mess with the base OS 
configuration unless absolutely necessary.  I am, BTW, the systems 
administrator.
  
> As for knowing about that choice, it is mentioned in the documentation,
> and in the inline help. Just as it is for "configure" style tools. You
> could have done a: bjam --help, and seen:

Yes, that is how this discussion got started.  I had followed the example in 
the documentation, and set my own directory for --prefix.  The way it's 
looking to me now, the whole /install/ action is spurious for my situation.  
Installing Boost means extracting it to the installation location and 
building it in place. Following that I need to set my environment variables 
to reference the appropriate locations. In the case of Boost I believe the 
best thing for me to do is:

#Assume BOOST_HOME to be my equivalent to BOOST_ROOT

test "$PWD" = "$BOOST_HOME" && ln -s stage/lib . && ln -s boost include

I will observe the $BOOST_HOME/bin directory does not seem to hold what I 
expect to find in a <path to>/bin directory.  

I did not refrence any documentation when writing the following, so it may be 
subject ot refinement or correction. 

My expectation of an installation is that it reflects the structure of a Unix 
file system.  In the following 'info' is not from standard Unix, but the 
remainder of the directory names are.  If you have BOOST_ROOT set 'correctly' 
this will generate the directory structure I would expect to find in a 
package installed on a Unix or Unix-like OS when --prefix=$BOOST_ROOT:

UP="lib bin include sbin man share libexec info";\
for d in $UP; do echo "$BOOST_ROOT/$d"; done

$BOOST_ROOT/lib # libraries for loading at runtime or linking at compile time
$BOOST_ROOT/bin # user executables such as bjam, etc
$BOOST_ROOT/include # header files intended for use by developers
$BOOST_ROOT/sbin # executables intended for systems administration
$BOOST_ROOT/man # Unix manual pages for Boost, if they exist
$BOOST_ROOT/share # platform independent resources: html docs, dtds, Jambase? 
$BOOST_ROOT/libexec # executables that I don't use very often.
$BOOST_ROOT/info # GNU Info documentation for Boost, if it exists

Since properly conforming (to GNU standards) GNU packages are predictable, I 
am able to do the following:

export GNU=$ORG/gnu

#test -z "$GNU_GCC" && export GNU_GCC=$GNU/gcc-3.4.0
#test -n "$GNU_GCC" || export GNU_GCC=$GNU/gcc-3.3.3
export GNU_MAKE=$GNU/make-3.80
export GNU_AUTOCONF=$GNU/autoconf-2.59
export GNU_AUTOGEN=$GNU/autogen-5.5.7
export GNU_AUTOMAKE=$GNU/automake-1.8.4
export GNU_GNOME=/opt/gnome
export GNU_LIBTOOL=$GNU/libtool-1.5.6
export GNU_TEXINFO=$GNU/texinfo-4.7
export GNU_EMACS=$GNU/emacs-cvs
#export GNU_DDD=$GNU/ddd-3.3.8
export GNU_GDB=$GNU/gdb-6.1
export GNU_DDD=$GNU/ddd-cvs
export GNU_LIB3DS=$GNU/lib3ds-1.2.0
export GNU_TOOLSMANUAL=$GNU//toolsmanual-0.1.5

export GNU_LIST="$GNU_TOOLSMANUAL\
 $GNU_LIB3DS\
 $GNU_DDD\
 $GNU_GDB\
 $GNU_EMACS\
 $GNU_TEXINFO\
 $GNU_LIBTOOL\
 $GNU_GNOME\
 $GNU_AUTOMAKE\
 $GNU_AUTOGEN\
 $GNU_AUTOCONF\
 $GNU_MAKE\
"
# $GNU_GCC\

GNU_MANPATH=""
GNU_PATH=""
GNU_INFOPATH=""
GNU_LIBRARY_PATH=""
GNU_INCLUDE_PATH=""

for g in $GNU_LIST;do
    GNU_MANPATH=$g/man:$GNU_MANPATH
    GNU_PATH=$g/bin:$GNU_PATH
    GNU_INFOPATH=$g/info:$GNU_INFOPATH
    GNU_LIBRARY_PATH=$g/lib:$GNU_LIBRARY_PATH
    GNU_INCLUDE_PATH=$g/include:$GNU_INCLUDE_PATH
done;

I then use the GNU_* variables to set the value of my standard environment 
variables. It's not perfect, but it is effective.  SuSE uses a somewhat 
different approach to configuration.  I believe what it amounts to is 
choosing a different order of traversal over a multiply connected graph.

>
> >>Typically bootstraps are used in the gnu world as a means of
> >>building the gcc compiler, or Emacs which needs to be able to
> >>compile its own Lisp.  They are not used after the first build, and
> >>do not become part of the installed package.
> >
> > Bootstrap has a more general meaning.
>
> Indeed it does... from Merriam-Webster:

Yes it can be used to describe the mechanism that sets a multivibrator built 
with vacuum tubes into oscillation, or to start a computer by loading 
instructions stored in firmware which cause the loading of instructions 
stored on a harddrive or other resource, such as a shared network image of a 
harddrive.  I use the term to describe starting any process that needs some 
crucial piece of information about itself.  As I pointed out earlier, it's 
not wrong to use words with different connotations in different situations, 
but it can be confusing.  I'm letting you know what was confusing to me when 
I read the documentation.  That does not necessarily mean the documentation 
is at fault.
-- 
Regards,
Steven