fix stylish-haskell makefile target
Description
1. Ensure .stylish-haskell.yaml is picked up properly.
2. Avoid descending into inappropriate subdirectories.
3. Pick up language extensions from the sub-projects' cabal files.
Failures to parse source files occurred by dint of not having language
extensions enabled according to the sub-projects' cabal files and the
global .yaml file. The global .yaml file's path is passed in as an
argument to the -c option at each invocation. It also descends into
sub-projects' directories to launch stylish-haskell invocations in order
to accommodate the limitations on stylish-haskell's search procedure
for cabal files. Furthermore, it propagates the precise failure exit codes
upstream to make while using iterative constructs that typically obscure
them, where the prior invocation via xargs returned a different exit code
from the one reported by the failing program (stylish-haskell). It also
post-processes messages on stderr to report the paths to filenames
referenced in error messages relative to the project root, where that
behaviour would have been disturbed by the usual format of reporting
during invocations from sub-directories of the project root.
Co-authored-by: Nadia Chambers <[email protected]>
Though he's not reviewed any changes afterwards, for the first commit in the sequence, also:
Co-authored-by: Clément Hurlin <[email protected]>
Checklist
- [X] Commit sequence broadly makes sense and commits have useful messages
- [X] New tests are added if needed and existing tests are updated. These may include:
- golden tests
- property tests
- roundtrip tests
- integration tests See Runnings tests for more details This is in itself a sort of test and build system utility.
- [X] Any changes are noted in the
CHANGELOG.mdfor affected package This falls beneath the threshold of notability for changelogging. - [X] The version bounds in
.cabalfiles are updated None are affected. - [x] CI passes. See note on CI. The following CI checks are required:
- [x] Code is linted with
hlint. See.github/workflows/check-hlint.ymlto get thehlintversion This is largely a build system patch, so hlint is of minimal relevance. - [X] Code is formatted with
stylish-haskell. See.github/workflows/stylish-haskell.ymlto get thestylish-haskellversion This is an update to the invocation of stylish-haskell in a .PHONY makefile target, so it's of minimal relevance. - [x] Code builds on Linux, MacOS and Windows for
ghc-8.10.7andghc-9.2.7
- [x] Code is linted with
- [X] Self-reviewed the diff There was a moderate amount of local testing.
How do I run this?
The following doesn't work:
make stylish-haskell
/bin/sh: 45: Syntax error: word unexpected
make: *** [Makefile:32: stylish-haskell] Error 2
make -v
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
make -v GNU Make 4.3 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
This is deal-breaking. Give me until I can get past this cough/cold whatever to do something that works with that make version or otherwise clears up the incompatibility you've discovered.
There is a way to trim this down after a fashion, as there are a couple of different things happening here.
- The one that fixes an outright failure to execute is actually just a fixup for some code in a not-taken branch of an #ifdef that stylish-haskell notes has a lexical error of embedding a newline in a string.
- The second thing is going about getting the appropriate Haskell extensions from the cabal files sitting above source files as well as the project-wide stylish-haskell config file, which involves changing directories to where the cabal files are seen in a path search.
- The third is error message post-processing so that the use of working directories below the project root doesn't give incomplete paths to the files being flagged as having errors in them.
Parts 2 and 3 don't seem to be as critical to getting the stylish-haskell target to stop erroring, though they do things that could be considered useful after a fashion. Some of the point of having this WIP PR out there was for people to say whether they might be worthwhile. That said, it might make sense for me to force the relevant branch of the #ifdef in the source-level fix to be taken (e.g. by temporarily changing the #ifdef condition) to at least make sure the lexically corrected source typechecks. It could also make sense to break out the long rule for the stylish-haskell target into a script.
make -v ...
My Ubuntu 22.04.2 LTS WSL image seemed to reproduce the failure you described & I did a little reworking of the commit series for clean-up bikeshedding etc. It's also stayed good on my NixOS 23.05 WSL image too. Whenever you get a chance, let me know how it looks to you.
Though there are approvals, as I recall Clément disliked some of the later changes in the sequence, and I've since been using some different scripts based on this branch. Comments on where people want to take this or if it's wanted at all are welcome.