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.
linux standalone: Generate locale files in ~/.cache/git-annex/locales/ so
they're available even when the standalone tarball is installed in a
directory owned by root.
This avoids a full-on reference counting cleanup hell, by letting old
locale caches linger as long as the standalone bundle directory associated
with them is still around. Old ones get cleaned up.
In the case where the directory has a new bundle unpacked over top of it,
the old locale cache is invalidated and rebuilt. Of course, running
programs using that may get confused, but this was already the case, and
unpacking over top of a bundle is probably not a good idea anyhow.
To support that, added a buildid file, which only needs to be unique across
builds of git-annex with different libc versions. sha1sum of git-annex
seems good enough for that.
Removed debian/patches/standalone-no-LOCPATH as it's no longer
necessary.
This commit was supported by the NSF-funded DataLad project.
This way, autobuilders can run it before building, in a tree where
git-annex was already built, and get the current git rev embedded in the
build.
Before, the version number only updated when the setup program was run,
which was up to cabal and not on every build.
Makefile: Remove chrpath workaround for bug in cabal, which is no longer
needed.
https://github.com/haskell/cabal/issues/2717 says it uses RUNPATH instead
of RPATH now, but I don't even see that for statically linked libraries;
the bug with that appears to be fixed.
cabal-install version 1.24.0.2
compiled using version 1.24.2.0 of the Cabal library
I left the rpath removal using otool on OSX because those straight up
broke the linker, and I don't know if the OSX autobuilder is updated to
a new enough cabal to not need it.
This commit was sponsored by Ewen McNeill on Patreon.
Test suite is always included.
Building with this flag disabled has actually been broken for some time,
since Command.TestRemote uses tasty. Fewer build flags are better, so good
time to drop it.
This commit was sponsored by Thomas Hochstein on Patreon.
This avoids warnings from stack about the module not being listed in the
cabal file. So, the generated file is also renamed to Build/SysConfig.
Note that the setup program seems to be cached despite these changes; I
had to cabal clean to get cabal to update it so that Build/SysConfig was
written.
This commit was sponsored by Jochen Bartl on Patreon.
If you run stack as root (e.g. for "make install"), any files it
creates under ./ will, of course, be owned by root. That's a
problem for subsequent runs as non-root.
Reduce the likelihood of that happening by building
Build/InstallDesktopFile during "make all", so that it needn't be
built by "make install".
optparse-applicative-0.14.0.0 adds support for these, so have the
Makefile install their scripts when built with it.
CmdLine/GitAnnex/Options.hs now uses action "file" in cmdParams,
which affects the bash and zsh completions, letting them complete
filenames for subcommands that use that. This is not needed for
bash, since bash-completion.bash enables -o bashdefault, which
lets it complete filenames too. But it does not seem to break the bash
completions. It is needed for zsh; the zsh completion otherwise
does not complete filenames. The fish completion will always complete
filenames no matter what. Messy.
This commit was sponsored by Denis Dzyubenko on Patreon.
This gets ghc installed if it's not already.
Motivation: Ævar's git test that runs git-annex test using git
can be called with BUILDER=stack, but without stack setup being run
sometime, the stack build will fail.
Otherwise, make reconfigures every time and then rebuilds all files.
I went too far in 3af9f5ed1a. All that's
needed is to make the configure target not use Build/SysConfig.hs as the
target name, so make won't delete that file after a failed build.
This commit was supported by the NSF-funded DataLad project
The problem with that target was, if a target like git-annex that
depended on it failed for some reason, make would delete
Build/SysConfig.hs, since it knows it's an intermediate file. But, since
stack only builds that file once, that caused all subsequent make git-annex
builds to fail.
Also, this avoids a double stack build when building with stack. Since
stack has no configure stage, and the Build/SysConfig.hs target was
about running the configure stage, the only way to only build once is to
combine the targets like this.
This should work better on the autobuilders that build with stack.
This commit was sponsored by NSF-funded DataLad project
Git does not provide a switch to find out where this directory is, and
while the git-init man page says it will always be in
/usr/share/git-core/templates, that's not the case on OSX with git
installed from homebrew. So, I used a hack taking the --man-path and
constructing a path from that. Works on both Debian and OSX at least.
