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

5 Sep 2004

      On Saturday 04 September 2004 22:56, Rene Rivera wrote:
...
David Abrahams wrote:
...
"Steven T. Hatton"  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