These are just some notes about third party libraries and how
they are or perhaps should be managed in VisIt. 

The table below is approximately how things are named currently.
However, there is much variation and so the table is more to
capture a desired goal than to document current usage.

Symbol name             Context     Where Defined           Where used       Description and Comments
------------------------------------------------------------------------------------------------------
DEFAULT_XXX_INCLUDE     configure   config-site/host.in     configure.in     Default location of XXX includes.
                                                                             No examples where it is overridden.
                                                                             Only the path, not with leading '-I'.

DEFAULT_XXX_LIB         configure   config-site/host.in     configure.in     Default location of XXX libs (.a/.so)
                                                                             No examples where it is overridden.
                                                                             Only the path, not with leading '-L'.
                                                                             Associated with --with-XXX=INC,LIB.
                                                                             Often one path sufficient to define both 
                                                                             Are there standard places we can search?

XXX_INCLUDE             configure   make-variables.in       make-variables.in config-time def'n for XXX_INCLUDE
XXX_INCLUDE             make        make-variables          Makefile         Location of XXX includes

XXX_LIB                 configure   make-variables.in       make-variables.in config-time def'n for XXX_LIB
XXX_LIB                 make        make-variables          Makefile         Location of XXX library file(s)

XXX_LIBS                configure   make-variables.in       make-variables.in config-time def'n for XXX_LIBS
XXX_LIBS                make        make-variables          Makefile         Linker directives for linking to XXX
                                                                             (e.g. "-lbox2D -lg2c")

HAVE_XXX_H              preprocessor visit-config           C++ sources      Compile-time symbol to check for
                                                                             existence of XXX's header files.
HAVE_XXX_LIB            preprocessor visit-config           C++ sources      Compile-time symbol to check for
                                                                             existence of XXX's library files.
                                                                             Why need one for header/lib??
XXX                     configure   configure.in            Makefile.in      config-time def'n for subdir
                                                                             containing code depending on XXX

Proposal for when VisIt's internal libraries may introduce dependencies on third party libraries...
---------------------------------------------------------------------------------------------------
LIB_VVV_LDFLAGS         configure   make-variables.in       make-variables.in config-time def'n for LIB_VVV_LDFLAGS
LIB_VVV_LDFLAGS         make        make-variables          Makefile         Location(s) of other libs VisIt's
                                                                             own VVV library depends on

LIB_VVV_LIBS            configure   make-variables.in       make-variables.in config-time def'n for LIB_VVV_LIBS
LIB_VVV_LIBS            make        make-variables          Makefile         Linker directives for linking to VVV
                                                                             when it has dependencies on other libs.

As libs are changed, how do we handle version compatibility so that if we
introduce code that is useable only in a given version of a lib, VisIt
can still compile with an older version of that lib?

We create a lot of links in VisIt's main lib directory that point
at other libs that VisIt uses. If that is so, why isn't it the case
that all we need everywhere in VisIt link link is a -L for the
main lib directory?

some libs needed only by given database plugin
   - if lib not available, plugin is not built. So, no need
     for HAVE_XXX compile time constants
   - not necessary to fiddle with LIB symbol because the
     lib is tacked on in plugin's makefile
   - libs often installed manually on various local
     platforms.
   - architecture specific install points vary and do not
     match VisIt's internal arch-specific install points.
   - often built as .a to avoid recursion in load of
     plugin's .sos with lib's .sos
   - use --with-lib=inc,lib to turn on off during configure
   - use DEFAULT_XXX_INCLUDE, DEFAULT_XXX_LIB for site config files

some libs used by visit internally (AND OPTIONALLY)
   -bzip2, zlib (where), silo (not essential but currently is)
   -need to fiddle with INCLUDE symbol(s) and LIB symbols
   -some tested with AC_CHECK_LIB (libsocket for example)
   -others use --enable-xxx configure controls
   -often need HAVE_XXX compile time symbols to avoid compiling
    lib dependent code when lib is not available
   -often check for existence of *both* .h and .a (.so) file, why?
   -visit's include point (visit/include) has links to specific
    lib's include files.

The way that silo's include path is handled is...
   - for siloobj, SILO_INCLUDE is added to SILOBJVTK_CPPPLAGS
     which are used specifically in siloobj Makefiles
   - for avtprep, SILO_INCLUDE is added to PREPROCESSOR_CPPFLAGS
     which is used specifically in prep Makefiles

Verdict library is part of visit

There are problems with carrying a lib around with visit
   - bigger distribution tarball
   - longer compile
   - multiple installations waste space due to duplicated
     lib
   - definately do not want sources being version controlled


So, it is best to get libs visit uses and install separately
   - HDF5, Boxlib and other database libs
   - verdict library
   - CSG rendering library if we ever have it
   - python, gl, vtk, qt
   - interval library
   - bzip2 library
   - other compression libs 
   - image magick stuff
   - some libs, like vtk, aren't easily swapable
   - if a lib is intended to replace something ordinarily
     found in system places, it requires special handling


But, its nice to have the option to produce a tarball with
all of them.

Here is an ideal scenario...

Visit vob has the tarballs as obtained from various sites
for various libs it uses, un-edited.

When visit gets installed on a given platform, it checks
to see if there is already the current (as determined by
contents of third_party tarballs) library compiled and
installed on that platform (by doing some comparison
between what the current tarball thinks it should have
and the "standard places" where standard places should
include previous installations of visit). If the lib is
not found, visit will untar and "install" that lib so
that not only the current installation of visit can proceed
with it but future versions of visit can link to it.


