Overhauled llvm/clang docs builds. Closes PR6613.

NOTE: 2nd part changeset for cfe trunk to follow.

*** PRE-PATCH ISSUES ADDRESSED

- clang api docs fail build from objdir
- clang/llvm api docs collide in install PREFIX/
- clang/llvm main docs collide in install
- clang/llvm main docs have full of hard coded destination
  assumptions and make use of absolute root in static html files;
  namely CommandGuide tools hard codes a website destination
  for cross references and some html cross references assume
  website root paths

*** IMPROVEMENTS

- bumped Doxygen from 1.4.x -> 1.6.3
- splits llvm/clang docs into 'main' and 'api' (doxygen) build trees
- provide consistent, reliable doc builds for both main+api docs
- support buid vs. install vs. website intentions
- support objdir builds
- document targets with 'make help'
- correct clean and uninstall operations
- use recursive dir delete only where absolutely necessary
- added call function fn.RMRF which safeguards against botched 'rm -rf';
  if any target (or any variable is evaluated) which attempts
  to remove any dirs which match a hard-coded 'safelist', a verbose
  error will be printed and make will error-stop.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103213 91177308-0d34-0410-b5e6-96231b3b80d8

1 files changed, 0 insertions, 49 deletions

diff --git a/docs/HistoricalNotes/2001-04-16-DynamicCompilation.txt b/docs/HistoricalNotes/2001-04-16-DynamicCompilation.txt
deleted file mode 100644
index 5f7843ab56..0000000000
--- a/docs/HistoricalNotes/2001-04-16-DynamicCompilation.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-By Chris:
-
-LLVM has been designed with two primary goals in mind.  First we strive to 
-enable the best possible division of labor between static and dynamic 
-compilers, and second, we need a flexible and powerful interface 
-between these two complementary stages of compilation.  We feel that 
-providing a solution to these two goals will yield an excellent solution 
-to the performance problem faced by modern architectures and programming 
-languages.
-
-A key insight into current compiler and runtime systems is that a 
-compiler may fall in anywhere in a "continuum of compilation" to do its 
-job.  On one side, scripting languages statically compile nothing and 
-dynamically compile (or equivalently, interpret) everything.  On the far 
-other side, traditional static compilers process everything statically and 
-nothing dynamically.  These approaches have typically been seen as a 
-tradeoff between performance and portability.  On a deeper level, however, 
-there are two reasons that optimal system performance may be obtained by a
-system somewhere in between these two extremes: Dynamic application 
-behavior and social constraints.
-
-From a technical perspective, pure static compilation cannot ever give 
-optimal performance in all cases, because applications have varying dynamic
-behavior that the static compiler cannot take into consideration.  Even 
-compilers that support profile guided optimization generate poor code in 
-the real world, because using such optimization tunes that application 
-to one particular usage pattern, whereas real programs (as opposed to 
-benchmarks) often have several different usage patterns.
-
-On a social level, static compilation is a very shortsighted solution to 
-the performance problem.  Instruction set architectures (ISAs) continuously 
-evolve, and each implementation of an ISA (a processor) must choose a set 
-of tradeoffs that make sense in the market context that it is designed for.  
-With every new processor introduced, the vendor faces two fundamental 
-problems: First, there is a lag time between when a processor is introduced 
-to when compilers generate quality code for the architecture.  Secondly, 
-even when compilers catch up to the new architecture there is often a large 
-body of legacy code that was compiled for previous generations and will 
-not or can not be upgraded.  Thus a large percentage of code running on a 
-processor may be compiled quite sub-optimally for the current 
-characteristics of the dynamic execution environment.
-
-For these reasons, LLVM has been designed from the beginning as a long-term 
-solution to these problems.  Its design allows the large body of platform 
-independent, static, program optimizations currently in compilers to be 
-reused unchanged in their current form.  It also provides important static 
-type information to enable powerful dynamic and link time optimizations 
-to be performed quickly and efficiently.  This combination enables an 
-increase in effective system performance for real world environments.