+ Prefer GHC 8.10.7 to 8.10.4, as versions seem to have stabilised now.
+ Add support for Stackage LTS 19; this ships with GHC 9.0.2.
+ Since a new version of 9.2 has been released, prefer 9.2.2 over 9.2.1.
Related: https://github.com/xmonad/xmonad-contrib/pull/694
Style guidelines should be where most people will see them. Since we
already ask people to read CONTIRBUTING.md when they submit a pull
request, putting them in there seems like the best place.
We can also drop the curious "or freer" clause from the licensing point,
much like xmonad-contrib@f39218ddb5ffeddce90f620910d5ef2c14f2b43d
already did.
utf8-string isn't needed since d9e3ebf531
(late 2014).
Most of the executable xmonad deps are unnecessary since
307b82a53d (early 2015).
Switch from data-default to data-default-class to avoid bringing in deps
and instances we don't need.
pandoc's API changes often enough that distros like Debian were patching
our GenerateManpage.hs to work with their version of pandoc, and it
doesn't build against any Stackage LTS except the recently released
LTS-17. Also, building pandoc from source takes quite some time and
resources.
But for what benefit? We're not using any special pandoc functionality
whatsoever. It's just that it was all in Haskell and the entire build
was orchestrated by cabal, but is all that complexity and resource
consumption worth it? I think not.
(Frankly, this whole thing was just a massive waste of time as the help
text in Config.hs isn't generated at all, so we still need to do this
manually. And then, the default key-bindings in core are unlikely to
change ever again.)
Let's simplify this:
* drop all dependencies except base and just run it through runhaskell
* add a Makefile and GH Actions workflow that invokes this after push
* only ship the results in release tarball, not the scripts which are
considered our dev infrastructure
Closes: https://github.com/xmonad/xmonad/issues/283
Related: https://github.com/xmonad/xmonad/pull/260
Related: https://github.com/xmonad/xmonad/pull/261
Related: https://github.com/xmonad/xmonad/pull/265
Related: https://github.com/xmonad/xmonad/pull/266
Related: https://github.com/xmonad/xmonad/pull/267
Related: https://github.com/xmonad/xmonad/pull/268
The tests are implemented by using a newtype wrapper `TestStack`. This is to
avoid creating `Eq1` and `Show1` instances for `Stack` itself, which are needed
by quickcheck-classes to run with GHC less than 8.5. Tests are automatically
generated by `traversalLaws` and `foldableLaws` using the `Arbitrary` instance
for `TestStack`.
`Functor` is provided by DeriveFunctor.
`Foldable` uses `integrate` (`Stack`'s `toList`).
`Traversable` uses the `Reverse` Applicative to traverse the `up` list in
reverse order.
This turns off the warnings about unused imports _unless_ one is using
the oldest supported version of GHC (right now that's 8.4.4 or older);
then it turns them into errors! This prevents xmonad from emitting
warnings about imports that have to be there due to backwards
compatibility, but are obsolete in newer versions (think MFP), while at
the same time preventing bitrot.
We can take advantage of modern Pandoc features to move information like the
release date, the man page section, etc. into the markdown source rather than
having to insert that data during the rendering process. The only thing that
remains to be figured out by this tool is the set of known key bindings.
A side effect of that change is that our code no longer compiles with GHC
versions prior to 8.0.x. We could work around that, no doubt, but the resulting
code would require CPP and Cabal flags and whatnot. It feels more reasonable to
just require a moderately recent compiler instead of going through all that
trouble.
- Our code does not compile with versions prior to 4.6, because we need
System.Environment.lookupEnv.
- Our code does not compile with version 4.12 (GHC 8.6.x) and beyond.
Closes https://github.com/xmonad/xmonad/issues/180.
Hackage won't accept the package with that "hack" in place. If you want to
compile with profiling enabled, please configure the build with
--enable-profiling via "cabal" or "stack" or whatever build driver you're
using.
