Move `/includes` to `/rts/include`, sort per package better

In order to make the packages in this repo "reinstallable", we need to
associate source code with a specific packages. Having a top level
`/includes` dir that mixes concerns (which packages' includes?) gets in
the way of this.

To start, I have moved everything to `rts/`, which is mostly correct.
There are a few things however that really don't belong in the rts (like
the generated constants haskell type, `CodeGen.Platform.h`). Those
needed to be manually adjusted.

Things of note:

 - No symlinking for sake of windows, so we hard-link at configure time.

 - `CodeGen.Platform.h` no longer as `.hs` extension (in addition to
   being moved to `compiler/`) so as not to confuse anyone, since it is
   next to Haskell files.

 - Blanket `-Iincludes` is gone in both build systems, include paths now
   more strictly respect per-package dependencies.

 - `deriveConstants` has been taught to not require a `--target-os` flag
   when generating the platform-agnostic Haskell type. Make takes
   advantage of this, but Hadrian has yet to.

3 files changed, 31 insertions, 31 deletions

diff --git a/docs/storage-mgt/ldv.tex b/docs/storage-mgt/ldv.tex
index ab2c8b9532..9084ae1ea4 100644
--- a/docs/storage-mgt/ldv.tex
+++ b/docs/storage-mgt/ldv.tex
@@ -100,7 +100,7 @@ all events associated with any closures and update necessary information.
 
 All events associated with closures are handled by one of the three 
 macros defined
-in @includes/StgLdv.h@: @LDV_recordCreate()@, @LDV_recordUse()@, and 
+in @rts/include/StgLdv.h@: @LDV_recordCreate()@, @LDV_recordUse()@, and 
 @LDV_recordDead()@.
 
 \begin{itemize}
@@ -145,10 +145,10 @@ typedef struct {
 \end{code}
 For instance, the LDV word of a closure @c@ can now be accessed with 
 @c->header.prof.hp.ldvw@ (or by @LDVW(c)@ where @LDVW()@ is a macro in 
-@includes/StgLdvProf.h@).
+@rts/include/StgLdvProf.h@).
 
 An LDV word is divided into three fields, whose position is specified
-by three constants in @includes/StgLdvProf.h@:
+by three constants in @rts/include/StgLdvProf.h@:
 \begin{itemize}
 \item{@LDV_STATE_MASK@} corresponds to the state flag. 
 \item{@LDV_CREATE_MASK@} corresponds to the creation time.
@@ -163,7 +163,7 @@ The creation time field and the most recent use time field can be set only by th
 macros @LDV_recordCreate()@ and @LDV_recordUse()@. 
 @LDV_recordCreate()@ must be called whenever a new dynamic closure is created,
 and this is handily accomplished by rewriting the macro @SET_PROF_HDR()@ 
-(in @includes/ClosureMacros.h@) (we do not need to change @SET_STATIC_PROF_HDR()@
+(in @rts/include/ClosureMacros.h@) (we do not need to change @SET_STATIC_PROF_HDR()@
 because static closures are not involved in LDVU profiling at all):
 
 \begin{code}
@@ -388,7 +388,7 @@ There are four cases in which a closure is destroyed:
 
 \begin{enumerate}
 \item A closure is overwritten with a blackhole: 
-  @UPD_BH_UPDATABLE()@ in @includes/StgMacros.h@,
+  @UPD_BH_UPDATABLE()@ in @rts/include/StgMacros.h@,
   @threadLazyBlackHole()@ and @threadSqueezeStack()@ in @GC.c@,
   the entry code for @BLACKHOLE@ closures in @StgMiscClosures.hc@ (a 
   @BLACKHOLE@ closure is changed into a @BLACKHOLE_BQ@ closure).
@@ -500,7 +500,7 @@ size, we invoke @LDV_recordDead_FILL_SLOP_DYNAMIC()@ only from:
 \item @threadLazyBlackHole()@ and @threadSqueezeStack()@ in @GC.c@
 (for lazy blackholing),
 \item @UPD_BH_UPDATABLE()@ in
-@includes/StgMacros.h@ (for eager blackholing, which isn't the
+@rts/include/StgMacros.h@ (for eager blackholing, which isn't the
 default),
 \item @updateWithIndirection()@ and @updateWithPermIndirection()@ 
 in @Storage.h@.\footnote{Actually slop words created in 
@@ -538,7 +538,7 @@ and no assumptions made upon LDVU profiling hold any longer.
 In order to yield correct LDVU profiling results, we must make sure
 that @LDV_recordUse()@ be called on a closure whenever it is used;
 otherwise, most of closures would be reported to be in the void phase.
-@includes/StgLdvProf.h@ provides an entry macro @LDV_ENTER@ which
+@rts/include/StgLdvProf.h@ provides an entry macro @LDV_ENTER@ which
 expands to @LDV_recordUse()@.  The compiler arranges to invoke
 @LDV_ENTER@ in the entry code for every dynamic closure it generates
 code for (constructors, thunks and functions).  We also have to add
@@ -629,10 +629,10 @@ are almost the same, though.
 
 This section gives a summary of changes made to the GHC in 
 implementing LDVU profiling.
-Only three files (@includes/StgLdvProf.h@, @LdvProfile.c@, and 
+Only three files (@rts/include/StgLdvProf.h@, @LdvProfile.c@, and 
 @LdvProfile.h@) are new, and all others exist in the GHC.
 
-@\includes@ directory:
+@\rts\include@ directory:
 
 \begin{description}
 \item[StgLdvProf.h] defines type @LdvGenInfo@, constants, and macros related
diff --git a/docs/storage-mgt/rp.tex b/docs/storage-mgt/rp.tex
index ced5c0cd4f..c0b7b5c904 100644
--- a/docs/storage-mgt/rp.tex
+++ b/docs/storage-mgt/rp.tex
@@ -212,21 +212,21 @@ directive as well unless otherwise mentioned.}
 \subsection{Adding a new field to Haskell closures} 
 
 We want to add a retainer set field of type @retainerSet@ to every 
-closure, so we create a new file @includes/StgRetainerProf.h@ where
+closure, so we create a new file @rts/include/StgRetainerProf.h@ where
 we define the type @retainerSet@.
 The actual definition of @retainerSet@ will be given later.
 
 \begin{code}
-/* includes/StgRetainerProf.h */
+/* rts/include/StgRetainerProf.h */
 typedef ... retainerSet;
 \end{code}
 
 We make type @retainerSet@ to be publicly available by including
-@includes/StgRetainerProf.h@ itself to @includes/Stg.h@ (not wrapped
+@rts/include/StgRetainerProf.h@ itself to @rts/include/Stg.h@ (not wrapped
 by @PROFILING@).
 
 \begin{code}
-/* includes/Stg.h */
+/* rts/include/Stg.h */
 #include "StgRetainerProf.h"
 \end{code}
 
@@ -254,14 +254,14 @@ of certain types of closures and their layout.
 When building the runtime system, the @gcc@ compiler correctly figures out
 the size of every structure on its own.
 However, 
-GHC simply reads @includes/Constants.h@ to determine the size of 
+GHC simply reads @rts/include/Constants.h@ to determine the size of 
 closures assumed by the runtime system.
 Thus, we must change the constants used by the GHC itself (as opposed to
-the runtime system). They are all found in @includes/Constants.h@.
+the runtime system). They are all found in @rts/include/Constants.h@.
 We increase each of them by 1 to reflect the retainer set field which is one 
 word long:
 \begin{code}
-/* includes/Constants.h */
+/* rts/include/Constants.h */
 #define PROF_HDR_SIZE       2
 #define SCC_UF_SIZE         5
 #define SCC_SEQ_FRAME_SIZE  4
@@ -269,7 +269,7 @@ word long:
 @PROF_HDR_SIZE@ denotes the size of the structure @StgProfHeader@, which
 is now two words long. 
 @SCC_UF_SIZE@ and @SCC_SEQ_FRAME_SIZE@ denote the size of the structures
-@StgUpdateFrame@ and @StgSeqFrame@ (in @includes/Closures.h@) in
+@StgUpdateFrame@ and @StgSeqFrame@ (in @rts/include/Closures.h@) in
 words.
 
 Now we must rebuild the GHC so that, when executed, the code generated by 
@@ -404,10 +404,10 @@ Finally we may need to initialize the retainer set field of an update frame
 (stack closure) when it is pushed onto the stack for the first time. 
 For instance, if we want to initialize the retainer set field of update
 frames to a null pointer, we can rewrite the macro @PUSH_STD_CCCS()@ 
-(in @includes/Updates.h@) as follows:
+(in @rts/include/Updates.h@) as follows:
 
 \begin{code}
-/* includes/Updates.h */
+/* rts/include/Updates.h */
 #define PUSH_STD_CCCS(frame)            \
   (frame->header.prof.ccs = CCCS, frame->header.prof.rs = NULL)
 \end{code}
@@ -418,10 +418,10 @@ Hence, the above modification is entirely unnecessary.
 Also, update frames are the only exception to the standard way of creating
 stack closures: all the other types of stack closures with a retainer set 
 field are eventually initialized by
-the macro @SET\_HDR()@ (in @includes/ClosureMacros.h@), which in turn
+the macro @SET\_HDR()@ (in @rts/include/ClosureMacros.h@), which in turn
 invokes @SET\_PROF\_HDR()@. This is not the case for update frames.
-Compare @PUSH\_UPD\_FRAME()@ (in @includes/Updates.h@) and  
-@PUSH\_SEQ\_FRAME()@ (in @includes/StgMacros.h@) for clarification.
+Compare @PUSH\_UPD\_FRAME()@ (in @rts/include/Updates.h@) and  
+@PUSH\_SEQ\_FRAME()@ (in @rts/include/StgMacros.h@) for clarification.
 
 \section{Retainer Sets}
 
@@ -439,7 +439,7 @@ implementation.
 The function @R()@ in Figure~\ref{fig-retaineralgorithm} returns
 the identity of a retainer. In order to implement it, we need 
 a type for retainer identity.
-The type @retainer@ (in @includes/StgRetainerProf.h@) is introduced for
+The type @retainer@ (in @rts/include/StgRetainerProf.h@) is introduced for
 this purpose. 
 
 There are various ways of defining the type @retainer@. 
@@ -470,7 +470,7 @@ retainer getRetainerFrom(StgClosure *c) { return c->header.prof.ccs; }
 \subsection{Retainer sets and the cost function}
 
 A retainer set is stored in the structure @retainerSet@ 
-(in @includes/StgRetainerProf.h@):
+(in @rts/include/StgRetainerProf.h@):
 
 \begin{code}
 typedef struct _retainerSet {
@@ -721,7 +721,7 @@ In addition to the thread closures, weak pointers are also considered
 as roots; they may not be reachable from any thread closure yet are still
 being in used.
 A weak pointer has three pointer fields: @key@, @value@, and 
-@finalizer@ (see the structure @StgWeak@ in @includes/Closures.h@).
+@finalizer@ (see the structure @StgWeak@ in @rts/include/Closures.h@).
 It turns out that these pointers may not be valid all the time:
 at a certain point during execution, for instance, the pointer @key@ may point 
 to a dead closure. 
@@ -875,7 +875,7 @@ A retainer profiling scheme specifies \emph{what} retainer profiling
 yields (as opposed to \emph{how} retainer profiling computes the retainer
 set for every live object).
 It is determined primarily by the meaning of retainer identity,
-that is, the type @retainer@ (in @includes/StgRetainerProf.h@). 
+that is, the type @retainer@ (in @rts/include/StgRetainerProf.h@). 
 The function @getRetainerFrom()@ must be defined according to the
 definition of the type @retainer@.
 
@@ -1032,10 +1032,10 @@ execution of retainer profiling.
 
 This section gives a summary of changes made to the GHC in 
 implementing retainer profiling.
-Only three files (@includes/StgRetainerProf.h@, @RetainerProfile.c@, and 
+Only three files (@rts/include/StgRetainerProf.h@, @RetainerProfile.c@, and 
 @RetainerProfile.h@) are new, and all others exist in the GHC.
 
-@\includes@ directory:
+@\rts\include@ directory:
 
 \begin{description}
 \item[StgRetainerProf.h] defines types @retainer@ and @retainerSet@. 
diff --git a/docs/storage-mgt/sm.tex b/docs/storage-mgt/sm.tex
index 4a52d61f5b..28941a5e73 100644
--- a/docs/storage-mgt/sm.tex
+++ b/docs/storage-mgt/sm.tex
@@ -620,7 +620,7 @@ objects whose contents can be updated and hence may contain pointers to
 younger generations. 
 Every object in this linked list is a dynamic object residing in the heap 
 and has a structure compatible with @StgMutClosure@.
-The structure @StgMutClosure@ (@includes/Closures.h@) has a field 
+The structure @StgMutClosure@ (@rts/include/Closures.h@) has a field 
 @mut_link@ (called a mutable link field) of type @StgMutClosure *@, which
 points to the next object in this linked list.
 The end mark of this linked list is a pointer to a statically allocated object 
@@ -655,14 +655,14 @@ contain static objects (as opposed to dynamic objects residing in the heap)
 in its list @mut_once_list@. This happens when a static
 thunk, also known as a \emph{constant applicative form} (CAF), is entered.
 When a CAF (corresponding to closure type @THUNK_STATIC@, defined
-in @includes/ClosureTypes.h@) is entered, 
+in @rts/include/ClosureTypes.h@) is entered, 
 it is first put in the list @mut_once_list@ of the oldest generation
 and then overwritten with an appropriate static indirection object 
 (corresponding to closure type @IND_STATIC@).\footnote{Actually a static 
 indirection object does not have a @mut\_link@ field.
 We use its @static\_link@ field as a substitute for @mut\_link@.
 See the structure @StgIndStatic@ in @include/Closures.h@.}\footnote{For
-details of this operation, see the macro @UPD\_CAF()@ in @includes/Updates.h@}
+details of this operation, see the macro @UPD\_CAF()@ in @rts/include/Updates.h@}
 If the CAF is dynamically loaded (e.g., in an interactive environment), it is 
 instead put in a separate linked list @caf_list@ 
 (declared in @Storage.c@).