Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | Move 'Platform' to ghc-boot | John Ericson | 2019-06-19 | 1 | -1/+1 |
| | | | | | | | ghc-pkg needs to be aware of platforms so it can figure out which subdire within the user package db to use. This is admittedly roundabout, but maybe Cabal could use the same notion of a platform as GHC to good affect too. | ||||
* | Maintain separate flags for C++ compiler invocations | Ben Gamari | 2019-06-13 | 1 | -1/+1 |
| | | | | | | | Previously we would pass flags intended for the C compiler to the C++ compiler (see #16738). This would cause, for instance, `-std=gnu99` to be passed to the C++ compiler, causing spurious test failures. Fix this by maintaining a separate set of flags for C++ compilation invocations. | ||||
* | Break up `Settings` into smaller structs | John Ericson | 2019-05-29 | 1 | -0/+203 |
As far as I can tell, the fields within `Settings` aren't *intrinsicly* related. They just happen to be initialized the same way (in particular prior to the rest of `DynFlags`), and that is why they are grouped together. Within `Settings`, however, there are groups of settings that clearly do share something in common, regardless of how they anything is initialized. In the spirit of GHC being a library, where the end cosumer may choose to initialize this configuration in arbitrary ways, I made some new data types for thoses groups internal to `Settings`, and used them to define `Settings` instead. Hopefully this is a baby step towards a general decoupling of the stateful and stateless parts of GHC. |