Been meaning to do this for some time; Android port was last straw.
Note that newer versions of the uuid library have a Data.UUID.V4 that
generates random UUIDs slightly more cleanly, but Debian has an old version
of the library, so I do it slightly round-about.
This allows it to use Build.SysConfig to always install the programs
configure detected. Amoung other fixes, this ensures the right uuid
generator and checksum programs are installed.
I also cleaned up the handling of lsof's path; configure now checks for
it in PATH, but falls back to looking for it in sbin directories.
Without the frameworks, but with this library, I get:
dyld: Symbol not found: __vproc_transactions_enable
Referenced from: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
Expected in: /Volumes/git-annex/git-annex.app/Contents/MacOS/./C
in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
Without this library, things seem to work again w/o frameworks.
Since I'm dealing with arbitrarily short fields in which to store the
library name, and would have to rebuild a bunch of stuff like git to avoid
that, and I have to prefix this obnoxiously long "@executable_path"
to it, it's easy to run out of space. This makes it use 1 and 2 letter long
filenames for libraries in the app. Fun fun fun fun fun.
This uses the ADNS library, if available. Otherwise, the host program.
I anticipate that cabal users won't easily get hsdns installed, since
it's a Haskell binding to a C library. And using host is just fine, as
long as the system has it.
So, it might be called sha1sum, or on some other OS, it might be called
sha1. It might be hidden away off of PATH on that OS. That's just expected
insanity; UNIX has been this way since 1980's. And these days, nobody even
gives the flying flip about standards that we briefly did in the 90's
after the first round of unix wars.
But it's the 2010's now, and we've certainly learned something.
So, let's make it so sometimes sha1 is a crazy program that wants to run as
root so it can lock memory while prompting for a passphrase, and outputting
binary garbage. Yes, that'd be wise. Let's package that in major Linux
distros, too, so users can stumble over it.
I put it in ~/.ssh/ because there's no reliable way to get it into PATH,
and OSX ssh doesn't even honor user's PATH by default.
authorized_keys generators will need to check if it's there. Not done yet.
I'm guessing that ~/Desktop/git-annex.app will be visiable.
For the system-wide installation, I don't know where to put it, though
somewhere in /Library seems likely.
git annex assistant --autostart will start separate daemons in each
listed autostart repo
running the webapp outside any git-annex repo will open it on the
first listed autostart repo
Test suite now passes with -threaded!
I traced back all the hangs with -threaded to System.Cmd.Utils. It seems
it's just crappy/unsafe/outdated, and should not be used. System.Process
seems to be the cool new thing, so converted all the code to use it
instead.
In the process, --debug stopped printing commands it runs. I may try to
bring that back later.
Note that even SafeSystem was switched to use System.Process. Since that
was a modified version of code from System.Cmd.Utils, it needed to be
converted too. I also got rid of nearly all calls to forkProcess,
and all calls to executeFile, which I'm also doubtful about working
well with -threaded.
Using Crypto's version of the hashes would be another option.
I need to benchmark it. The SHA2 library (which provides SHA1 also,
confusing name) may be the fastest option, but is not currently in Debian.
Don't check if configure indicated checks won't work. This should fix a
FTBFS on mipsel, where configure correctly detects the checks won't work,
while garbage is returned for disk space info at git-annex runtime. It also
means that, when built via cabal, disk space checks are not enabled,
unfortunatly.
Rather than running make, which runs configure, let Setup.hs just include
the configure code. The standalone configure is retained for use by the
Makefile.
This may work better with cabal-dev, since it avoids the Makefile running
ghc, and lets cabal handle all the compiler running, with whatever
flags it uses to expose dependencies.
