Add comments/todos.
[hadrian.git] / doc / meeting-25-September-2015.txt
1 Shaking up GHC meeting, 25 September 2015\r
2 \r
3 Things to discuss:\r
4 ================================================\r
5 \r
6 1. Progress report\r
7 ------------------\r
8 \r
9 Done:\r
10 * Build all libraries and compiler\r
11 * Generate code (alex, happy, hsc2hs, genprimopcode, Config.hs, ghc_boot_platform.h)\r
12 * Track changes in the build system\r
13 * Extract accurate package dependencies from .cabal files\r
14 * Improve complexity when searching for module files (40x)\r
15 \r
16 Todo:                                   Target:\r
17 * Build utils, rts & put in GHC tree    October\r
18 * Better dependencies (.hs-incl etc.)   November\r
19 * Support command line options          December\r
20 * Validate                              November-December\r
21 * Documentation                         December-January\r
22 * Journal paper + provenance                    December-February\r
23 \r
24 Notes:\r
25 * Zero build: under 7 seconds\r
26 * Full build (when compilation not required): under 12 minutes on 4 cores\r
27 * Limited parallelism: ghc-cabal/ghc-pkg not thread-safe, ghc fails on > 4 cores\r
28 * Codebase growing: 50 files\r
29 \r
30 Things to do:\r
31 -- Use OrderOnly for ordering ghc-cabal's\r
32 -- Fix parallel invokations of ghc-cabal\r
33 -- Fix GHC -M to handle .hs-incl (--make already knows how to do that) instead of writing a new parser. Maybe already done -- find a flag!\r
34 -- Rename files -> outputs, sources -> inputs\r
35 -- Start separating general bits from GHC bits. A separate package for Args maybe\r
36 -- Look up Bazel and Buck\r
37 -- Decompose args into builder-specific and package-specific\r
38 \r
39 2. Seemingly dead-code\r
40 ----------------------\r
41 \r
42 I used to carefully migrate all code to the new build system even when it seemed dead, but this is often getting in the way of readability. New proposal: drop all such suspicious instances and bring them back only if/when things break. \r
43 \r
44 Example (generating primops.txt):\r
45 \r
46 C:/msys/home/chEEtah/ghc/inplace/mingw/bin/gcc.exe -E -undef -traditional -P -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header  -Icompiler/stage2 -x c compiler/prelude/primops.txt.pp | grep -v '^#pragma GCC' > compiler/stage2/build/primops.txt\r
47 \r
48 But primops.txt.pp has no lines containing #pragma GCC. Dead code?\r
49 \r
50 Another example (generating ghc_boot_platform.h):\r
51 \r
52 ifeq "$(TargetOS_CPP)" "irix"\r
53     @echo "#ifndef $(IRIX_MAJOR)_TARGET_OS"                   >> $@\r
54     @echo "#define $(IRIX_MAJOR)_TARGET_OS 1"                 >> $@\r
55     @echo "#endif"                                            >> $@\r
56 endif\r
57 \r
58 But IRIX_MAJOR is never set anywhere in the build system. Dead code? YES\r
59 \r
60 \r
61 3. Command line options\r
62 -----------------------\r
63 \r
64 Discuss the need for command line options, e.g. 'make GhcDebugged=YES'. Do we need to  support all options as in the old build system?\r
65 \r
66 Settings.User is fairly readable, so perhaps some options may be changeable only by editing this file and recompiling the build system (typically takes negligible time compared to building). This will simplify things. Can we come up with a must-have list for command line options?\r
67 \r
68 -- Try to support these first:\r
69 * EXTRA_HC_OPTS = file "asd" ? arg ".."\r
70 * EXTRA_CC_OPTS \r
71 * GhcDebugged = True\r
72 * make 2\r
73 \r
74 \r
75 4. Better names for build stages\r
76 --------------------------------\r
77 \r
78 Currently we have Stage0, Stage1, etc. It is not particularly clear from the names what they stand for (as a newcomer to the build system I used to look up what these numbers stand for all the time). Shall we use this opportunity to pick more helpful names, for example:\r
79 \r
80 Stage0 -> Boot    \r
81 Stage1 -> Interim \r
82 Stage2 -> Install \r
83 Stage3 -> Selftest\r
84 \r
85 \r
86 5. Do we need a name for the new build system?\r
87 ----------------------------------------------\r
88 \r
89 * At least we need a name for the folder in the GHC tree.\r
90 \r
91 * If we call it 'shake' there may be a confusion with the Shake library.\r
92 \r
93 * In future discussions/announcements/etc. calling it 'the new shake-based\r
94   build system' is overly verbose. Calling it 'shake' is confusing.\r
95 \r
96 * I haven't thought about any names yet, just checking whether we want to. \r
97 \r
98 -- Use mk2