Re: Building the docs, again
Hello, never mind, I figured it out---apparently the build targets were disabled for the `quick` flavor, which I was using. It is quite confusing that we can be setting the same variable to different values in different places. It would also be quite helpful if we modified the Makefile to say `documentation build target is disabled` or some such, rather then going ahead and building the whole of GHC, only at the end to inform me that it doesn't know what is `html`. -Iavor On Tue, Oct 31, 2017 at 2:26 PM Iavor Diatchki wrote: > Hello, > > sometime ago, I asked if it is possible to build just the GHC docs, > without building the compiler. I was told to just run `make html`. This > does not appear to work, the command seems to just start building GHC. > What am I doing wrong? > > Here is the output I see, running the command from the root of the GHC > tree. > > > make html V=0 > ===--- building phase 0 > make --no-print-directory -f ghc.mk phase=0 phase_0_builds > make[1]: Nothing to be done for 'phase_0_builds'. > ===--- building phase 1 > make --no-print-directory -f ghc.mk phase=1 phase_1_builds > HC [stage 0] compiler/stage1/build/BufWrite.o > HC [stage 0] compiler/stage1/build/Pretty.o > compilation IS NOT required > HC [stage 0] compiler/stage1/build/PprColour.o > compilation IS NOT required > HC [stage 0] compiler/stage1/build/Outputable.o > compilation IS NOT required > HC [stage 0] compiler/stage1/build/Json.o > compilation IS NOT required > HC [stage 0] compiler/stage1/build/SrcLoc.o > compilation IS NOT required > HC [stage 0] compiler/stage1/build/BasicTypes.o > compilation IS NOT required > HC [stage 0] compiler/stage1/build/Unique.o > HC [stage 0] compiler/stage1/build/Packages.o-boot > compilation IS NOT required > HC [stage 0] compiler/stage1/build/FiniteMap.o > compilation IS NOT required > HC [stage 0] compiler/stage1/build/Name.o-boot > > (then I interrupted it). > > Also, in `mk/config.mk` I see this: > BUILD_SPHINX_HTML= YES > > -Iavor > > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Building the docs, again
Hello, sometime ago, I asked if it is possible to build just the GHC docs, without building the compiler. I was told to just run `make html`. This does not appear to work, the command seems to just start building GHC. What am I doing wrong? Here is the output I see, running the command from the root of the GHC tree. > make html V=0 ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds HC [stage 0] compiler/stage1/build/BufWrite.o HC [stage 0] compiler/stage1/build/Pretty.o compilation IS NOT required HC [stage 0] compiler/stage1/build/PprColour.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Outputable.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Json.o compilation IS NOT required HC [stage 0] compiler/stage1/build/SrcLoc.o compilation IS NOT required HC [stage 0] compiler/stage1/build/BasicTypes.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Unique.o HC [stage 0] compiler/stage1/build/Packages.o-boot compilation IS NOT required HC [stage 0] compiler/stage1/build/FiniteMap.o compilation IS NOT required HC [stage 0] compiler/stage1/build/Name.o-boot (then I interrupted it). Also, in `mk/config.mk` I see this: BUILD_SPHINX_HTML= YES -Iavor ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHCi recompilation avoidance UI
I updated the trac ticket, but here's a copy-paste: I still don't feel like 1 is necessary, I'd rather flags cause other flags to be ignored with a warning, rather than turn on other flags. But that's just a vague preference, with no strong evidence for it. Maybe it could emit a warning if you didn't put -fobject-code in explicitly, e.g. "-O implies -fobject-code, adding that flag." So as long as we accept 1, then 2 and 3 follow naturally. Given that, I support this UI. Thanks for looking into it! ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
[ANNOUNCE] GHC 8.2.2 release candidate 2
Hello everyone, The GHC team is very pleased to announce the second candidate of the 8.2.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.2-rc2/ This is the second and hopefully last of two release candidates leading up the final 8.2.2 release. This release fixes approximately fifty bugs present in 8.2.1. These most notably include, * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) See [1] for the full list. As always, please report any issues you encounter. Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
GHCi recompilation avoidance UI
Changes in GHC 8.2.1 lead to a lot of recompilation, because GHCi now refuses to load optimized code unless -fobject-code (and optimization flags) are enabled. I propose the following slight modification to https://ghc.haskell.org/trac/ghc/ticket/13604#comment:48 1. Optimization flags (except -O0) imply -fobject-code. This ensures that GHC respects optimization flags regardless of --interactive. 2. Even when -fobject-code is on, :load *M will load M as bytecode. This provides the "escape hatch" from -fobject-code that you need to use debugging features, etc. 3. New -fignore-optim-changes and -fignore-hpc-changes (Phab:D4123) flags should enable users to put together object code and bytecode with diverse optimization levels/options and HPC options while still updating automatically based on source changes and whether profiling is enabled. Does this seem like a reasonable way forward? David Feuer ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
