Here are hpack package.yaml files for the other hledger cabal files.
These remove a lot of human-error-prone duplication.
They are not used yet as hpack isn't quite mature enough -
when it supports flags and benchmarks we will probably switch.
hakyll-std's cabal file is now generated by hpack from an easier yaml
config file, which looks like a valuable timesaver. "make gencabalfiles"
will regenerate this cabal file (and soon the others) when needed.
The makefile now uses stack primarily.
The following updated rules are available:
$ make
Makefile:35: -------------------- hledger make rules --------------------
Makefile:37: make [help] -- list documented rules in this makefile. make -n RULE shows more detail.
Makefile:202: (INSTALLING:)
Makefile:204: make install -- download dependencies and install hledger executables to ~/.local/bin or equivalent (with stack)
Makefile:229: (BUILDING:)
Makefile:233: make build -- download dependencies and build hledger executables (with stack)
Makefile:302: make hledgerdev -- quickly build the hledger executable (with ghc and -DDEVELOPMENT)
Makefile:487: (TESTING:)
Makefile:495: make test -- run default tests
Makefile:541: make pkgtest -- run the test suites for each package
Makefile:548: make builtintest -- run tests built in to the hledger executable (subset of pkg tests)
Makefile:572: make functest -- run hledger functional tests with the stack build
Makefile:606: make haddocktest -- run haddock and make sure it succeeds
Makefile:787: (DOCUMENTATION:)
Makefile:895: make haddock -- generate haddock docs for the hledger packages
Makefile:974: (RELEASING:)
Makefile:1053: make setversion -- update all version strings to match .version
Makefile:1056: make setversionforce -- update all version strings even if .version seems unchanged
Makefile:1080: make tagrelease -- commit a release tag based on .version for each package
Makefile:1253: (MISCELLANEOUS:)
Makefile:1255: make usage -- show size of various dirs
Makefile:1260: make stackusage -- show size of stack working dirs
Makefile:1264: make cabalusage -- show size of cabal working dirs if any
Makefile:1268: make tag -- generate tag files for source code navigation (for emacs)
Makefile:1294: make clean -- default cleanup (ghc build leftovers)
Makefile:1297: make Clean -- thorough cleanup (stack/cabal/ghc builds and tags)
Makefile:1302: make cabalCMD -- run cabal CMD inside each hledger package directory
Makefile:1306: make all"CMD" -- run CMD inside each hledger package directory
Refactored and enhanced the --width option used by register (and other
commands in future). register now uses the full terminal width by
default except on windows. Specifically, the output width is set from:
1. a --width option
2. or a COLUMNS environment variable (NB: not the same as a bash shell var)
3. or on POSIX (non-windows) systems, the current terminal width
4. or the default, 80 characters.
Also, register now accepts a description column width as part of
--width's argument, comma-separated (--width W,D). This adjusts the
relative widths of register's description and account columns, which are
normally about half of (W-40):
<--------------------------------- width (W) ---------------------------------->
date (10) description (D) account (W-41-D) amount (12) balance (12)
DDDDDDDDDD dddddddddddddddddddd aaaaaaaaaaaaaaaaaaa AAAAAAAAAAAA AAAAAAAAAAAA
Examples:
$ hledger reg # use terminal width on posix
$ hledger reg -w 100 # width 100, equal description/account widths
$ hledger reg -w 100,40 # width 100, wider description
$ hledger reg -w $COLUMNS,100 # terminal width and set description width
Fed up with GHC/cabal constantly assaulting me like Cato in a Pink
Panther movie, here are some shell tests to give me some
warning/reassurance about the dev setup on various machines.
Thou Shalt Not Reimplement Autoconf, but perhaps a little cross-platform
test suite focussed on my needs is a reasonable idea.
I've moved the installation and developer guides, FAQ and how-tos from
hledger.org (yst & git) to hledger.org/wiki (dokuwiki) and tried to
integrate their navigation bars two as best I can. Using just one
or the other would be nice, but I don't think I can quite do that;
it seems the manual at least should be revision controlled along with the code.
