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.

llvm-svn: 103213

1 files changed, 0 insertions, 31 deletions

diff --git a/llvm/docs/HistoricalNotes/2001-07-06-LoweringIRForCodeGen.txt b/llvm/docs/HistoricalNotes/2001-07-06-LoweringIRForCodeGen.txt
deleted file mode 100644
index 3e10416fe67..00000000000
--- a/llvm/docs/HistoricalNotes/2001-07-06-LoweringIRForCodeGen.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Date: Fri, 6 Jul 2001 16:56:56 -0500
-From: Vikram S. Adve <vadve@cs.uiuc.edu>
-To: Chris Lattner <lattner@cs.uiuc.edu>
-Subject: lowering the IR
-
-BTW, I do think that we should consider lowering the IR as you said.  I
-didn't get time to raise it today, but it comes up with the SPARC
-move-conditional instruction.  I don't think we want to put that in the core
-VM -- it is a little too specialized.  But without a corresponding
-conditional move instruction in the VM, it is pretty difficult to maintain a
-close mapping between VM and machine code.  Other architectures may have
-other such instructions.
-
-What I was going to suggest was that for a particular processor, we define
-additional VM instructions that match some of the unusual opcodes on the
-processor but have VM semantics otherwise, i.e., all operands are in SSA
-form and typed.  This means that we can re-generate core VM code from the
-more specialized code any time we want (so that portability is not lost).
-
-Typically, a static compiler like gcc would generate just the core VM, which
-is relatively portable.  Anyone (an offline tool, the linker, etc., or even
-the static compiler itself if it chooses) can transform that into more
-specialized target-specific VM code for a particular architecture.  If the
-linker does it, it can do it after all machine-independent optimizations.
-This would be the most convenient, but not necessary.
-
-The main benefit of lowering will be that we will be able to retain a close
-mapping between VM and machine code.
-
---Vikram
-