project: added a 'rationale' section to the README document.

1 files changed, 25 insertions, 0 deletions

diff --git a/README b/README
index 3fd11b7..e2be044 100644
--- a/README
+++ b/README
@@ -15,6 +15,31 @@ between packages, and is most noticeable in builds that invoke libtool a large
 number of times, and which are characterized by the short compilation time of
 individual translation units.
 
+## why reimplement libtool?
+
+Midipix targets use the PE binary format and so require import library
+integration on the one hand, yet follow ELF naming conventions
+(i.e. libfoo.so.x.y.z) on the other. In consequence, midipix shared
+libraries are not fully supported by existing libtool implementations.
+As an interim solution used for the porting of gcc, a libtool script
+generated by ltmain.sh was hand-edited so that it would correctly produce
+the host's shared libraries as part of the toolchain build process.
+
+Bypassing the libtool script generated by a package's ltmain.sh requires
+overriding the `LIBTOOL` variable as part of invoking `make(1)`. In that
+sense, and unless midipix support is added to every single ltmain.sh in
+every single package that uses autotools, it does not truly matter whether
+the surrogate libtool that one chooses be a script, a program written in C,
+or something else.
+
+At the time of this writing, an average libtool script consists of about
+`10K lines of code` with `several hundred case-esac statements` and a similar
+number of `if-then blocks`. In view of the length of the generated script,
+and in light of its challenging logic and overall complexity, a rewrite of
+the tool in C seemed to be the right choice not only with respect to quality,
+readability, and anticipated performance, but also in terms of development
+effort, ease of customization, and long-term maintenance.
+
 ## Requirements for building slibtool
 
 - a C toolchain, consisting of...