dde2e45ebd95be1f220f8d2ff3663ca55503a2e9
[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                      October\r
18 * Better dependencies (.hs-incl etc.)   November\r
19 * Support command line options          December\r
20 * Validate                              November-December (GHC 8.0?)\r
21 * Documentation                         December-January\r
22 \r
23 Notes:\r
24 * Zero build: under 7 seconds\r
25 * Full build (when compilation not required): under 12 minutes on 4 cores\r
26 * Limited parallelism: ghc-cabal/ghc-pkg not thread-safe, ghc fails on > 4 cores\r
27 * Codebase growing: 50 files\r
28 \r
29 \r
30 2. Seemingly dead-code\r
31 ----------------------\r
32 \r
33 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
34 \r
35 Example (generating primops.txt):\r
36 \r
37 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
38 \r
39 But primops.txt.pp has no lines containing #pragma GCC. Dead code?\r
40 \r
41 Another example (generating ghc_boot_platform.h):\r
42 \r
43 ifeq "$(TargetOS_CPP)" "irix"\r
44     @echo "#ifndef $(IRIX_MAJOR)_TARGET_OS"                   >> $@\r
45     @echo "#define $(IRIX_MAJOR)_TARGET_OS 1"                 >> $@\r
46     @echo "#endif"                                            >> $@\r
47 endif\r
48 \r
49 But IRIX_MAJOR is never set anywhere in the build system. Dead code?\r
50 \r
51 \r
52 3. Command line options\r
53 -----------------------\r
54 \r
55 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
56 \r
57 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
58 \r
59 \r
60 4. Better names for build stages\r
61 --------------------------------\r
62 \r
63 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
64 \r
65 Stage0 -> Boot    \r
66 Stage1 -> Interim \r
67 Stage2 -> Install \r
68 Stage3 -> Selftest\r
69 \r
70 \r
71 5. Do we need a name for the new build system?\r
72 ----------------------------------------------\r
73 \r
74 * At least we need a name for the folder in the GHC tree.\r
75 \r
76 * If we call it 'shake' there may be a confusion with the Shake library.\r
77 \r
78 * In future discussions/announcements/etc. calling it 'the new shake-based\r
79   build system' is overly verbose. Calling it 'shake' is confusing.\r
80 \r
81 * I haven't thought about any names yet, just checking whether we want to. \r