All: Update openssl to 1.0.1h/290662, curl to 290664, llqtwebkit to 290663.

Linux:  Include libQtXml and libQtSvg in manifest for libqsvg.so.
More documentation thoughts for library package structure.

1 files changed, 44 insertions, 2 deletions

diff --git a/indra/cmake/00-COMPILE-LINK-RUN.txt b/indra/cmake/00-COMPILE-LINK-RUN.txt
index 8f72448fe9..d08cc2dc0c 100644
--- a/indra/cmake/00-COMPILE-LINK-RUN.txt
+++ b/indra/cmake/00-COMPILE-LINK-RUN.txt
@@ -10,7 +10,7 @@ Introduction
     with hints and rules about doing things well.  What's presented is
     a guideline only.  Not all suggestions are hard rules and you'll
     find exceptions all over.  Some exceptions arise from solid
-    reasining, others may be legacy that hasn't been re-examined.
+    reasoning, others may be legacy that hasn't been re-examined.
 
     Use good engineering judgement when applying this information.
 
@@ -244,7 +244,7 @@ Futures
     So, what to do?  My natural bias for large software is to use
     shared libraries for everything.  It's a path to single-version
     and singleton data and isolates namespaces and prevents
-    interactions.  It also has some field servicability benefits if
+    interactions.  It also has some field serviceability benefits if
     you need to debug some bizarre problem a user has.
 
     But there's a local preference for static.  Here, my
@@ -281,6 +281,48 @@ Futures
     decide what changes you need here as those changes will propagate
     outwards forcing many other decisions (cf: /Zc:wchar_t- flag).
 
+    The current package structure (./include, ./lib/release,
+    ./lib/debug, etc.) really works against the conventions used by
+    configure-like programs.  I wasted a lot of time getting each
+    library to work with our structure without having to go back to
+    automake/autoconf.  For Linux and Mac (and even for Windows), a
+    structure like the following where each grouping is optional would
+    probably save some work:
+
+        ./debug/bin
+               /include
+               /lib
+        ./debug/shared/bin
+                      /include
+                      /lib
+        ./debug/static/bin
+                      /include
+                      /lib
+        ./release/bin
+                 /include
+                 /lib
+        ...
+
+    In zlib and openssl and in a few of the libraries that consume
+    them, I experimented with packaging both static and shared
+    libraries and then having the consumer library move the unwanted
+    pieces out of the way to use the library type of choice (see
+    restore_dylibs() and restore_sos() functions).  It was a bit fussy
+    and simplicity and clarity are the keys to maintaining libraries
+    in the future.
+
+    But it did suggest another approach.  The idea is that every build
+    pre-stages inputs.  Before anything is built, package pieces are
+    copied or symlinked from the 'stage/packages' area to the
+    'stage/input' area.  Builds then proceed with a single set of
+    -I/-L options for the dependencies.  And products are built and
+    installed in a similar output staging structure for the next
+    consumer:
+
+        stage/packages/<package>/[above structure]
+        stage/input/{bin,include,lib}
+        stage/<package>/[above structure]
+
     Next library project.  I'd recommend working on the related set of
     libexpat, apr, aprutil, xmlrpc-epi.  We know libexpat has some
     updates that should improve stability.  Libapr consumes it and it