The icon files will be installed when running make install or cabal
install. Did not try to run update-icon-caches, since I think it's debian
specific, and dh_icons will take care of that for the Debian package.
Using the favicon as a 16x16 icon. At 24x24 the svg displays pretty well,
although the dotted lines are rather faint. The svg is ok at all higher
resolutions.
The standalone linux build auto-installs the desktop and autostart files
when run. I have not made it auto-install the icon file too, because
a) that would take more work to include them in the tarball and find them
b) it would need to be an install to ~/.icons/, and I don't know if that
really works!
That's needed in files used to build the configure program.
For the other files, I'm keeping my __WINDOWS__ define, as I find that much easier to type.
I may search and replace it to use the mingw32_HOST_OS thing later.
Run the same code git-annex used to get the sha, including its sanity
checking. Much better than old grep. Should detect FreeBSD systems with
sha commands that output in stange format.
Now oberon has some binaries and libraries that use rpath, so I had to put
in this ugly hack to replace the @rapth/lib with the lib in the app.
This was particularly tricky for libraries that use @rpath because I could
not find a way to extract the rpath from the library. (Only from the
executable, by running it.. ugh!) The hack I put in place may fail if
multiple different libraries use rpath to refer to other libraries,
and the "@rpath/lib" string is the same, but actually refers to different
files.
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.
