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

diff --git a/docs/HistoricalNotes/2001-02-13-Reference-MemoryResponse.txt b/docs/HistoricalNotes/2001-02-13-Reference-MemoryResponse.txt
deleted file mode 100644
index 505343378d..0000000000
--- a/docs/HistoricalNotes/2001-02-13-Reference-MemoryResponse.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-Date: Tue, 13 Feb 2001 18:25:42 -0600
-From: Vikram S. Adve <vadve@cs.uiuc.edu>
-To: Chris Lattner <sabre@nondot.org>
-Subject: RE: LLVM Concerns...
-
-> 1. Reference types
->    Right now, I've spec'd out the language to have a pointer type, which
->    works fine for lots of stuff... except that Java really has
->    references: constrained pointers that cannot be manipulated: added and
->    subtracted, moved, etc... Do we want to have a type like this?  It
->    could be very nice for analysis (pointer always points to the start of
->    an object, etc...) and more closely matches Java semantics.  The
->    pointer type would be kept for C++ like semantics.  Through analysis,
->    C++ pointers could be promoted to references in the LLVM
->    representation.
-
-
-You're right, having references would be useful.  Even for C++ the *static*
-compiler could generate references instead of pointers with fairly
-straightforward analysis.  Let's include a reference type for now.  But I'm
-also really concerned that LLVM is becoming big and complex and (perhaps)
-too high-level.  After we get some initial performance results, we may have
-a clearer idea of what our goals should be and we should revisit this
-question then.
-
-> 2. Our "implicit" memory references in assembly language:
->    After thinking about it, this model has two problems:
->       A. If you do pointer analysis and realize that two stores are
->          independent and can share the same memory source object,
-
-not sure what you meant by "share the same memory source object"
-
-> there is
->          no way to represent this in either the bytecode or assembly.
->       B. When parsing assembly/bytecode, we effectively have to do a full
->          SSA generation/PHI node insertion pass to build the dependencies
->          when we don't want the "pinned" representation.  This is not
->          cool.
-
-I understand the concern.  But again, let's focus on the performance first
-and then look at the language design issues.  E.g., it would be good to know
-how big the bytecode files are before expanding them further.  I am pretty
-keen to explore the implications of LLVM for mobile devices.  Both bytecode
-size and power consumption are important to consider there.
-
---Vikram
-