Make whenever cabal configure is run with new cabal, and I don't need
100 copies of that to be backed up.

In Makefile, listed additional deps of Build/Standalone. Without that,
it does not get updated for the change to Utility/LinuxMkLibs.hs when
compiling incrementally.

Sponsored-by: Dartmouth College's DANDI project

Reverts a change accidentially committed in 09edb07a

debuglocks is minimal cost, but there is some and this was an accidental
change

to track down a blocked indefinitely on MVar that seems to occur after
sqlite throws ErrorBusy but that I have not been able to reproduce when
I made commits synthetically throw ErrorBusy.

Sponsored-by: Dartmouth College's Datalad project

hothasktags was removed from Debian. And in the meantime hasktags
improved so it works well in the source tree.

Also make dev update tags.

Sponsored-by: Jack Hill on Patreon

2fc46e18 broke running ./git-annex test
when git-annex-shell is not in PATH from another install, and also
caused the wrong git-annex-shell to be tested.

Using a symlink made programPath return the .cabal/ directory where the
git-annex binary is, but git-annex-shell is not in that directory.
Changing to a hard link avoids that problem.

Sponsored-by: Dartmouth College's Datalad project

hothasktags dropped emacs support, and probably emacs users will use
haskell-language-server rather than tags, I guess

That is now enabled by -f-Production, since commit
cab398c9

This may or may not make the OSX build work on a newer version of OSX
than the one that's currently being used for release builds. I have not
been able to find good docs about how exactly to get back from such a
value to the actual path to the library that the linker would use.

No need to end it with " git-annex"

This does not need to be cryptogrphically secure, and a little shorter
will be better when using the buildid in a path in subsequent changes.

need to build git-annex 1st, otherwise otool can't run

This includes making Build.Standalone run LinuxMkLibs or OSXMkLibs
rather than doing that separately. Which is groundwork for a later
optimisation.

Also it simplified the code some.

cabal exec in v2 puts the built binary in PATH, so can just ask where it
is that way, and symlink it

And cabal exec hothasktags simplifies running that, because it sets up
most of the necessary environment.

The tags and TAGS targets now need cabal v2 to work.

unfortunately old builds for old versions can linger in there

The old make fast machinery doesn't work at all with it, but it seems
actually reasonably fast now to just disable optimisation, so made make
dev do that. And it sticks once used, which is handy.

Removed hdevtools hack, which won't work. There are ide integrations
that really solve the problem that hack was working around.

Misc fixes for dist-newstyle location.

ridiculous that these editors use such similar names and different file
formats

(actually, if you force vim to read TAGS, it seems able to parse it, but
I can't find much documentation about that)

Seems unncessary and was a bit weird.

I tried the --recursive option of hothasktags but the vi tags file grew
by some orders of magnitude and also the emacs TAGS file contained many
wrong entries.

I deleted trailing whitespace in the Makefile since emacs warns about it
on save.

Unfortunately, cabal puts the binary in a very complicated path
and does not provide any good way to get it out, leaving no good choice
except to use find.

It may be possible to use cabal (new-)install --symlink-bindir,
and ask it to symlink to pwd, but with my older version of cabal,
that does not work.

The stack branch will probably also break once it uses a newer cabal,
didn't try to deal with that.

Build was succeeding despite the dmg never being created.

hdiutil create -format UDBZ -size 640m -srcfolder tmp/build-dmg \
		-volname git-annex -o tmp/git-annex.dmg
hdiutil: create failed - Resource busy

Sometimes it has failed this way for weeks until reboot. Sometimes a single
retry makes it work. Despite many reports of this problem, I have never
found for an explanation for it, other than <shrug> OSX.

Homebrew now has eg:

datalads-imac:~ joey$ ls -l /Users/joey/homebrew/Cellar/git/2.23.0/libexec/git-core
total 36776
lrwxr-xr-x   1 joey  staff       13 Aug 29 13:38 git -> ../../bin/git
lrwxr-xr-x   1 joey  staff       13 Aug 29 13:38 git-add -> ../../bin/git

So the target of the symlink also needs to be installed now.

Doing it in shell code was too hairy for my dentistry-addled brain, so
reimplemented in haskell. Also using it for building linuxstandalone.

This allows the rpm to be built anywhere the necessary build deps are
available (including on debian) and the resulting package will work on as
broad a range of rpm distributions as the libc/kernel supports.

The DistributionUpdate changes to use the new script have not yet been
tested.

Systems such as Debian that have overridden the default fpath will need to
set ZSH_COMPLETIONS_PATH.

I feel that Debian is causing unncessary complexity by making this change,
and have filed a bug report about it.

This also means that when git-annex is installed with PREFIX=/usr/local
it will use /usr/local/share/zsh/site-functions which works with probably
all versions of zsh.

git-annex build-depends on a new enough optparse-applicative that zsh
and fish completions will always be generated

Since it runs git-annex to generate the completions files.