| 291 | | |
| 292 | | each time '''make''' is invoked, it first invokes `inc.mk` with `PHASE=0`. |
| 293 | | This brings `inc1.mk` up-to-date (and ''only'' `inc1.mk`). The second |
| 294 | | time we invoke '''make''', we can be sure that `inc1.mk` is up-to-date and |
| 295 | | proceed to generate `inc2.mk`. This is not at all pretty, and |
| | 291 | Each time '''make''' is invoked, we recursively invoke '''make''' in several |
| | 292 | ''phases'': |
| | 293 | * '''Phase 0''': invoke `inc.mk` with `PHASE=0`. This brings `inc1.mk` |
| | 294 | up-to-date (and ''only'' `inc1.mk`). |
| | 295 | * '''Phase 1''': the second time we invoke '''make''', we can be sure |
| | 296 | that `inc1.mk` is up-to-date and proceed to generate `inc2.mk`. |
| | 297 | If this changes `inc2.mk`, then '''make''' automatically re-invokes itself, |
| | 298 | repeating Phase 1. |
| | 299 | We could have abandoned '''make''''s automatic re-invocation mechanism altogether, |
| | 300 | and used three phases, but in practice it's very convenient to use the automatic |
| | 301 | re-invocation in the final phase. However no automatic re-invocation should happen |
| | 302 | in any phase except the final one. |
| | 303 | |
| | 304 | In the case of the GHC build system we need 4 such phases, see the |
| | 305 | comments in the top-level `ghc.mk` for details. |
| | 306 | |
| | 307 | This approach is not at all pretty, and |