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, 55 deletions

diff --git a/docs/HistoricalNotes/2002-05-12-InstListChange.txt b/docs/HistoricalNotes/2002-05-12-InstListChange.txt
deleted file mode 100644
index 004edb068d..0000000000
--- a/docs/HistoricalNotes/2002-05-12-InstListChange.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-Date: Sun, 12 May 2002 17:12:53 -0500 (CDT)
-From: Chris Lattner <sabre@nondot.org>
-To: "Vikram S. Adve" <vadve@cs.uiuc.edu>
-Subject: LLVM change
-
-There is a fairly fundemental change that I would like to make to the LLVM 
-infrastructure, but I'd like to know if you see any drawbacks that I 
-don't...
-
-Basically right now at the basic block level, each basic block contains an 
-instruction list (returned by getInstList()) that is a ValueHolder of 
-instructions.  To iterate over instructions, we must actually iterate over 
-the instlist, and access the instructions through the instlist.
-
-To add or remove an instruction from a basic block, we need to get an 
-iterator to an instruction, which, given just an Instruction*, requires a 
-linear search of the basic block the instruction is contained in... just 
-to insert an instruction before another instruction, or to delete an 
-instruction!  This complicates algorithms that should be very simple (like 
-simple constant propogation), because they aren't actually sparse anymore, 
-they have to traverse basic blocks to remove constant propogated 
-instructions.
-
-Additionally, adding or removing instructions to a basic block 
-_invalidates all iterators_ pointing into that block, which is really 
-irritating.
-
-To fix these problems (and others), I would like to make the ordering of
-the instructions be represented with a doubly linked list in the
-instructions themselves, instead of an external data structure.  This is 
-how many other representations do it, and frankly I can't remember why I 
-originally implemented it the way I did.
-
-Long term, all of the code that depends on the nasty features in the 
-instruction list (which can be found by grep'ing for getInstList()) will 
-be changed to do nice local transformations.  In the short term, I'll 
-change the representation, but preserve the interface (including 
-getInstList()) so that all of the code doesn't have to change.
-
-Iteration over the instructions in a basic block remains the simple:
-for (BasicBlock::iterator I = BB->begin(), E = BB->end(); I != E; ++I) ...
-
-But we will also support:
-for (Instruction *I = BB->front(); I; I = I->getNext()) ...
-
-After converting instructions over, I'll convert basic blocks and 
-functions to have a similar interface.
-
-The only negative aspect of this change that I see is that it increases 
-the amount of memory consumed by one pointer per instruction.  Given the 
-benefits, I think this is a very reasonable tradeoff. 
-
-What do you think?
-
--Chris