Followed the instructions over here: http://git-annex.branchable.com/forum/git-annex_on_OSX/
and had to install the following extra packages to be able to get make to start:
[realizes pcre-light is needed but pcre not installed on my mac]
sudo port install pcre
sudo cabal install pcre-light
Ah right, that is a new dependency. I've updated the forum page with this info. --Joey
But then I got the following error:
ghc -O2 -Wall --make git-annex [ 7 of 52] Compiling BackendTypes ( BackendTypes.hs, BackendTypes.o BackendTypes.hs:71:17: No instance for (Arbitrary Char) arising from a use of `arbitrary' at BackendTypes.hs:71:17-25 Possible fix: add an instance declaration for (Arbitrary Char) In a stmt of a 'do' expression: backendname <- arbitrary In the expression: do backendname <- arbitrary keyname <- arbitrary return $ Key (backendname, keyname) In the definition of `arbitrary': arbitrary = do backendname <- arbitrary keyname <- arbitrary return $ Key (backendname, keyname) make: *** [git-annex] Error 1
My knowledge of Haskell (had to lookup the spelling...) is more than rudimentary so any help would be appreciated.
Hmm, it seems you may be missing part of the quickcheck haskell library, or have a different version than me.
The easy fix is probably to just edit BackendTypes.hs and delete the entire end of the file from line 68, "for quickcheck" down. This code is only used by the test suite (so "make test" will fail), but it should get it to build. --Joey
Closing this bug because the above problem now has a solution documented on the install page, and the below test suite failure problems should all be resolved on OSX. done --Joey
Thanks to your feedback, I got it going.
Maybe those two should be added to the 'OSX how-to' in the forum
[realizes pcre-light is needed but pcre not installed on my mac]
sudo port install pcre
sudo cabal install pcre-light
[tests are failing, need haskell's quickcheck]
sudo cabal install quickcheck
I'm running ghc 6.12.3 with the corresponding haskell-platform package from the HP site which I installed in preference to the macports version of haskell-platform (it's quite old). it seems when you install quickcheck, the version that is installed is of version 2.4.0.1 and not 1.2.0 which git-annex depends on for its tests.
it fails with this
I'd imagine if I could downgrade, it would compile and pass the tests (I hope)
I doubt that git-annex can be used with QuickCheck 1.2.0. The QuickCheck I've tested it with is 2.1.0.3 actually.
I suspect you have an old version of the TestPack haskell library on your system, that is linked against QuickCheck 1.2.0. Git-annex has been tested with TestPack 2.0.0, which uses QuickCheck 2.x.
In any case, you don't have to run 'make test' to build git-annex, and my comments above should make the main program compile, I expect.
Ah, that gave me a good clue, my system just got pretty confused with a mixture of quickcheck and testpack installs. Would it be possible to put up a list of versions of the software you are using on your development environment? (at least the minimum tested version)
I guess it shouldn't matter to most users who are going to rely on packagers to sort these dependancy issues, but it's nice to know.
Anyway, the tests build now, and they seem to fail on my (rather messy) install of haskell platform + ghc 6.12 on osx 10.6.6.
I assumed that since the tests built, then running them shouldn't be a problem. It looks like some argument isn't being passed about for the location of the .t directory that gets created. I will check the dependancies on my system again.
You're missing the sha1sum command, everything else is a followon error from that. Added a hint about this to install, and in the next version configure will check for sha1sum.
That's odd, I have the md5sha1sum package installed and it still fails with pretty much the same error
the configure script finds sha1sum, builds and starts to run.
a0826293 fixed the last problem, there is coreutils available in macports, if they are installed you get the gnu equivalents but they are prefixed with a g (e.g. gchmod instead of chmod), I guess not everyone will have these install or prefer these on OSX
Some more tests fail now...
On a side note, I think I found another bug in the testing. I had tested in a virtual machine in archlinux (a very recent updated version) Please see the report here tests fail when there is no global .gitconfig for the user
The dtrace puzzlingly does not have the same errors shown above, but a set of mostly new errors. I don't know what to make of that.
This seems to be caused by it setting the execute bit on the file. I don't know why that would fail; it's just written the file and renamed it into place so clearly should be able to write to it.
This also suggests something breaking with permissions.
It may be possible that OSX has some low resource limits, for user processes (266 per user I think) doing a
seems to change the behaviour of the tests abit...
the number of failures vary as I change the values of the maxprocs, I think I have narrowed it down to OSX just being stupid with limits thus causing the tests to fail.
Yeap, that did the trick. I just tested a few separate OSX 10.6.6 systems and the tests are better behaved now, only 3 failures now.
So the tests behave better (at least we don't get resource fork errors any more)
On all the systems I tested on, I'm down to 3 failures now.
It's the same set of failures across all the OSX systems that I have tested on. Now I just need to figure out why there are still these three failures.
I think I have figured out why
It goes back to the this piece of code (in test.hs)
It seems that on OSX it does not preserve the symbolic link information, basically cp is not gnu cp on OSX, doing a "cp -a SOURCE DEST" seem's to the right thing on OSX. I tried it out on my archlinux workstation by replacing -pr with just -a and all the tests passed on archlinux.
I'm not sure what the implications would be with changing the test with changing the cp command.
On second thought and after some messing (trying most of the options and combinations of options on OSX for).... I tried replacing cp with gnu cp from coreutils on my OSX install, and all the tests passed. sigh cp -a is preserving some permissions and attributes but not all, its not behaving in the same way as the gnu cp does... the closet thing that I have found on OSX that behaves in the same way as gnu "cp -pr" is to use "ditto".
Just doing a "ditto SOURCE DEST" in the tests passes everything. I'm not sure if its a good idea to use this even though it works. Though this is just the tests, does it affect CopyFile.hs where "cp" is called?
Outside the test suite, git-annex's actual use of cp puts fairly low demands on it. It tries to use cp -a or cp -p if available just to preserve whatever attributes it can preserve, but the worst case if that you have a symlink pointing to a file that doesn't have the original timestamp or whatever. And there's little expectation git preserves that stuff anyway.
I will probably try to make the test suite entirely use git clone rather than cp.