cabal exec will sometimes output other messages to stdout, which
broke the build. It used to be intermittent in CI, now seems to always
happen. Messages are eg "Resolving dependencies..."
It seems that cabal list-bin never does this. I hope.
cabal list-bin is fairly new, needing cabal 3.8, which is only in Debian
testing/unstable. So fall back to cabal exec if it fails.
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
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
2fc46e1871 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
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.
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.
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)
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.
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.
The location of the cabal_macros.h file has changed. Also, need to
tell hothasktags about language extensions that are enabled by default
in the cabal file.
This commit was sponsored by Thomas May.
Running git-annex linux builds in termux seems to work well enough that the
only reason to keep the Android app would be to support Android 4-5, which
the old Android app supported, and which I don't know if the termux method
works on (although I see no reason why it would not).
According to [1], Android 4-5 remains on around 29% of devices, down from
51% one year ago.
[1] https://www.statista.com/statistics/271774/share-of-android-platforms-on-mobile-devices-with-android-os/
This is a rather large commit, but mostly very straightfoward removal of
android ifdefs and patches and associated cruft.
Also, removed support for building with very old ghc < 8.0.1, and with
yesod < 1.4.3, and without concurrent-output, which were only being used
by the cross build.
Some documentation specific to the Android app (screenshots etc) needs
to be updated still.
This commit was sponsored by Brett Eisenberg on Patreon.
