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

diff --git a/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt b/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt
deleted file mode 100644
index 7b9032742a..0000000000
--- a/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt
+++ /dev/null
@@ -1,89 +0,0 @@
-> But in fact, if you read the entire answer carefully, he came to the same
-> conclusion I do: that you have to go with familiar syntax over logical
-> syntax because familiarity is such a strong force:
->       "However, familiarity is a strong force. To compare, in English, we
-live
-> more or less happily with the absurd rules for "to be" (am, are, is, been,
-> was, were, ...) and all attempts to simplify are treated with contempt or
-> (preferably) humor. It be a curious world and it always beed."
-
-Although you have to remember that his situation was considerably
-different than ours.  He was in a position where he was designing a high
-level language that had to be COMPATIBLE with C.  Our language is such
-that a new person would have to learn the new, different, syntax
-anyways.  Making them learn about the type system does not seem like much
-of a stretch from learning the opcodes and how SSA form works, and how
-everything ties together...
-
-> > Basically, my argument for this type construction system is that it is
-> > VERY simple to use and understand (although it IS different than C, it is
-> > very simple and straightforward, which C is NOT).  In fact, I would assert
-> > that most programmers TODAY do not understand pointers to member
-> > functions, and have to look up an example when they have to write them.
-
-> Again, I don't disagree with this at all.  But to some extent this
-> particular problem is inherently difficult.  Your syntax for the above
-> example may be easier for you to read because this is the way you have been
-> thinking about it.  Honestly, I don't find it much easier than the C syntax.
-> In either case, I would have to look up an example to write pointers to
-> member functions.
-
-I would argue that because the lexical structure of the language is self
-consistent, any person who spent a significant amount of time programming
-in LLVM directly would understand how to do it without looking it up in a
-manual.  The reason this does not work for C is because you rarely have to
-declare these pointers, and the syntax is inconsistent with the method
-declaration and calling syntax.
-
-> But pointers to member functions are nowhere near as common as arrays.
-
-Very true.  If you're implementing an object oriented language, however,
-remember that you have to do all the pointer to member function stuff
-yourself.... so everytime you invoke a virtual method one is involved
-(instead of having C++ hide it for you behind "syntactic sugar").
-
-> And the old array syntax:
->       type [ int, int, ...]
-> is just much more familiar and clear to people than anything new you
-> introduce, no matter how logical it is.  
-
-Erm... excuse me but how is this the "old array syntax"?  If you are
-arguing for consistency with C, you should be asking for 'type int []',
-which is significantly different than the above (beside the above
-introduces a new operator and duplicates information
-needlessly).  Basically what I am suggesting is exactly the above without
-the fluff.  So instead of:
-
-       type [ int, int, ...]
-
-you use:
-
-       type [ int ]
-
-> Introducing a new syntax that may
-> make function pointers easier but makes arrays much more difficult seems
-> very risky to me.
-
-This is not about function pointers.  This is about consistency in the
-type system, and consistency with the rest of the language.  The point
-above does not make arrays any more difficult to use, and makes the
-structure of types much more obvious than the "c way".
-
-> > In my opinion, it is critically important to have clear and concise type
-> > specifications, because types are going to be all over the programs.
-> 
-> I absolutely agree.  But the question is, what is more clear and concise?
-> The syntax programmers are used to out of years of experience or a new
-> syntax that they have never seen that has a more logical structure.  I think
-> the answer is the former.  Sometimes, you have to give up a better idea
-> because you can't overcome sociological barriers to it.  Qwerty keyboards
-> and Windows are two classic examples of bad technology that are difficult to
-> root out.
-
-Very true, but you seem to be advocating a completely different Type
-system than C has, in addition to it not offering the advantages of clear
-structure that the system I recommended does... so you seem to not have a
-problem with changing this, just with what I change it to.  :)
-
--Chris
-