BRL-CAD bundles a number of external libraries and tools critical to its
functionality.  To ensure such dependencies are reliably available, we maintain
a local copy of the code directly in src/other.  When our goal is to have the
third party code in question be usable in its unaltered upstream form, and we
can (at least in principle) use an installed system version of the dependency
if present, we place that dependency one level down in src/other/ext.  Ideally,
src/other/ext should consist solely of copies of vanilla upstream codes.

Unfortunately the actual state of src/other/ext can't always perfectly reflect
this ideal, so the decision of whether a code belongs in ext can be somewhat
nuanced.  An example would be our copy of zlib;  we modify it to allow us to
compile and link against it without introducing conflicts with system copies of
zlib brought in by other dependencies or customer codes.  Thus far we've not
successfully upstreamed those mods - however, if we are NOT bundling zlib, we
are fine with compiling against a vanilla system version - thus, zlib (even
though modded in our tree) fits best in src/other/ext.  Similarly, our netpbm
is an extraction of a subset of netpbm focused on the formats of interest to
us, with a CMake build system added and a mod to remove a problematically
licensed file.  However, since we can use a system netpbm if available it too
lives in ext.

The top level src/other libraries on the other hand (i.e. those NOT in the ext
subdirectory) represent situations where a system version of a library is not
viable.  Typically this occurs for one of two reasons:

 * We have taken over maintenance of a project where there is no longer an
   active upstream.

 * We need changes or features upstream is not likely to accept.

While we are maintaining these codes, they are not part of BRL-CAD proper and
we don't apply the full rigor of our coding standards to these repositories
(for example, we don't enforce the use of libbu substitutes for improved
behavior of some common functions.)

Because viable system versions of these libraries aren't going to exist, we
build them directly with add_subdirectory (and, when necessary, create CMake
builds for them to make this viable.)  If we aren't faced with the need to
detect and use system versions of dependencies a basic add_subdirectory
approach simplifies the build logic considerably. (The ext build techniques
have overhead in the form of rather sophisticated custom logic that allows us
to tie their build systems into our main build - we only want to pay that cost
when necessary to preserve the independence of upstream build logic.)

In those cases where the src/other code has an active upstream we do want to
try and stay as current as possible, but not at the expense of compromising the
functionality we need.

The specifics of each code currently present as a toplevel src/other directory
are as follows:


* libosmesa	https://github.com/starseeker/osmesa

This library is a subset of Mesa 7.0.4 that provides off-screen software
rasterizing and rendering per the OpenGL 2.1 standard.  This is the last
version of Mesa to not require extensive external dependencies. As the code was
written circa 2008 it needed various clean-ups, and is obviously not active
upstream - although the Mesa project in general is quite active (as of 2022) it
has removed this particular implementation altogether in favor of more modern
and performant code (which is also more complicated and dependency heavy).  We
have extracted just the pieces necessary for OpenGL v2 rendering in order to
use it for both an offscreen scene rendering option and a fallback of last
resort if system OpenGL capabilities aren't working.  It is a fully self-
contained C library, with no external dependencies, which makes it relatively
straightforward to keep working indefinitely.  We are not interested in
expanding its capabilities - it has what is needed to support BRL-CAD's basic
visualization features - so once working there should be little need to change
this code. (Modulo periodic modernization for newer compilers/standards.)  Note
that BRL-CAD's visualization capabilities in general should NOT remain tied to
OpenGL 2.1 - more modern/elaborate visualizations should use newer libraries
and standards.  This is intended strictly for offscreen/testing/fallback/
last-resort cases.


* libutahrle	https://www.cs.utah.edu/gdc/projects/urt

Utah run length encoded format - used by image processing tools.  This is a
fairly obscure image format, and as far as we know there is no active upstream
for this library.  We have stripped down the original toolkit to just the
library used by BRL-CAD tools.  Like libosmesa, this code is not coupled to any
external dependencies and is relatively straightforward to maintain
indefinitely, given periodic modernizations.


* lmdb		https://github.com/LMDB/lmdb

Lightning Memory-Mapped Database - fast key/value store from the OpenLDAP
project.  Doesn't have a Windows build system, so we provide one, along with
DLL import/export logic.  Upstream appears to manage lmdb as part of OpenLDAP,
so there's no particular expectation that our additions would be of interest.
Otherwise, we want to keep this one current with upstream changes.  Used to
support Level-of-Detail data management code.


* openNURBS	https://github.com/mcneel/opennurbs

Non-Uniform Rational B-Splines library, primarily focused on reading and
writing Rhino's 3DM file format but also provides a number of useful data
structures and algorithms for working with NURBS data types.  Foundation on
which NURBS support is built in libbrep and librt.  The vanilla openNURBS
implementation doesn't always compile on our targeted compilers/platforms and
requires some small logic changes - we have tried upstreaming in the past
without much success, so we maintain our own copy to ensure we have the
capability we need.  In principle we would like to stay current with upstream,
but that must be done cautiously with this library because of how central it is
to core raytracing functionality.


* poly2tri	https://github.com/jhasse/poly2tri.git

poly2tri is a constrained Delaunay triangulation library, primarily used during
NURBS tessellation.  We have made various changes to this code over the years
to try and improve its robustness for our use case.


* tkhtml	http://tkhtml.tcl.tk/tkhtml.html

Tcl/Tk widget used for HTML rendering of man pages in MGED and Archer.  No
active upstream, requires a cross platform build system.


* tktable	https://sourceforge.net/projects/tktable

Tcl/Tk table widget used in Archer.  Little to no upstream activity.  Requires
a cross platform build system.

