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