|
1 | 1 | <div class="hidden-warning"><a href="https://docs.haskellstack.org/"><img src="https://rawgit.com/commercialhaskell/stack/master/doc/img/hidden-warning.svg"></a></div>
|
2 | 2 |
|
3 |
| -# Build Overview |
| 3 | +# Build overview |
4 | 4 |
|
5 |
| -__NOTE__ This document should *not be considered accurate* until this |
6 |
| -note is removed. |
| 5 | +!!! warning |
7 | 6 |
|
8 |
| -This is a work-in-progress document covering the build process used by Stack. |
9 |
| -It was started following the Pantry rewrite work in Stack (likely to |
10 |
| -land as Stack 2.0), and contains some significant changes/simplifications from |
11 |
| -how things used to work. This document will likely not fully be reflected in |
12 |
| -the behavior of Stack itself until late in the Stack 2.0 development cycle. |
| 7 | + This document should not be considered accurate until this warning is |
| 8 | + removed. |
| 9 | + |
| 10 | + This is a work-in-progress document covering the build process used by |
| 11 | + Stack. It was started following the Pantry rewrite work in Stack 2.1.1, and |
| 12 | + contains some significant changes/simplifications from how things used to |
| 13 | + work. This document will likely not fully be reflected in the behavior of |
| 14 | + Stack itself until late in the Stack 2.0 development cycle. |
13 | 15 |
|
14 | 16 | ## Terminology
|
15 | 17 |
|
@@ -65,7 +67,8 @@ This file is parsed to provide the following config values:
|
65 | 67 | * `ghc-options` (optional field, defaults to `{}`)
|
66 | 68 |
|
67 | 69 | `flags` and `ghc-options` break down into both _by name_ (applied to a
|
68 |
| -specific package) and _general_ (general option `*` for flags is only available in CLI). |
| 70 | +specific package) and _general_ (general option `*` for flags is only available |
| 71 | +in CLI). |
69 | 72 |
|
70 | 73 | ## Wanted compiler, dependencies, and project packages
|
71 | 74 |
|
@@ -95,9 +98,12 @@ specific package) and _general_ (general option `*` for flags is only available
|
95 | 98 | in the corresponding package cabal file, it's an error.
|
96 | 99 | * We are now left with the following:
|
97 | 100 | * A wanted compiler version
|
98 |
| - * A map from package name to immutable packages with package config (flags, GHC options, hidden) |
99 |
| - * A map from package name to mutable packages as dependencies with package config |
100 |
| - * A map from package name to mutable packages as project packages with package config |
| 101 | + * A map from package name to immutable packages with package config (flags, |
| 102 | + GHC options, hidden) |
| 103 | + * A map from package name to mutable packages as dependencies with package |
| 104 | + config |
| 105 | + * A map from package name to mutable packages as project packages with |
| 106 | + package config |
101 | 107 |
|
102 | 108 | ## Get actual compiler
|
103 | 109 |
|
@@ -202,8 +208,10 @@ a hash of the following information:
|
202 | 208 | Motivation: Any package built from the immutable dependency map and
|
203 | 209 | installed in this database will never need to be rebuilt.
|
204 | 210 |
|
205 |
| -*FIXME* Caveat: do we need to take profiling settings into account |
206 |
| -here? How about Haddock status? |
| 211 | +!!! bug "To do" |
| 212 | + |
| 213 | + Caveat: do we need to take profiling settings into account here? How about |
| 214 | + Haddock status? |
207 | 215 |
|
208 | 216 | ## Determine actual target components
|
209 | 217 |
|
@@ -233,10 +241,12 @@ We now have a set of tasks of packages/components to build, with full
|
233 | 241 | config information for each package, and dependencies that must be
|
234 | 242 | built first.
|
235 | 243 |
|
236 |
| -*FIXME* There's some logic to deal with cyclic dependencies between |
237 |
| -test suites and benchmarks, where a task can be broken up into |
238 |
| -individual components versus be kept as a single task. Need to |
239 |
| -document this better. Currently it's the "all in one" logic. |
| 244 | +!!! bug "To do" |
| 245 | + |
| 246 | + There's some logic to deal with cyclic dependencies between test suites and |
| 247 | + benchmarks, where a task can be broken up into individual components versus |
| 248 | + be kept as a single task. Need to document this better. Currently it's the |
| 249 | + "all in one" logic. |
240 | 250 |
|
241 | 251 | ## Unregister local modified packages
|
242 | 252 |
|
|
0 commit comments