cabal can now be used to build git-annex.
This is substantially slower than using make, does not build or install documentation, does not run the test suite, and is not particularly recommended, but could be useful to some.
This commit is contained in:
parent
b3aaf980e4
commit
56aeeb4565
9 changed files with 96 additions and 27 deletions
1
.gitignore
vendored
1
.gitignore
vendored
|
@ -16,3 +16,4 @@ html
|
|||
Touch.hs
|
||||
StatFS.hs
|
||||
Remote/S3.hs
|
||||
dist
|
||||
|
|
6
Makefile
6
Makefile
|
@ -11,6 +11,8 @@ mans=git-annex.1 git-annex-shell.1 git-union-merge.1
|
|||
|
||||
all: $(bins) $(mans) docs
|
||||
|
||||
sources: SysConfig.hs StatFS.hs Touch.hs Remote/S3.hs
|
||||
|
||||
SysConfig.hs: configure.hs TestConfig.hs
|
||||
$(GHCMAKE) configure
|
||||
./configure
|
||||
|
@ -19,8 +21,10 @@ SysConfig.hs: configure.hs TestConfig.hs
|
|||
hsc2hs $<
|
||||
perl -i -pe 's/^{-# INCLUDE.*//' $@
|
||||
|
||||
Remote/S3.o:
|
||||
Remote/S3.hs:
|
||||
@ln -sf S3real.hs Remote/S3.hs
|
||||
|
||||
Remote/S3.o: Remote/S3.hs
|
||||
@if ! $(GHCMAKE) Remote/S3.hs; then \
|
||||
ln -sf S3stub.hs Remote/S3.hs; \
|
||||
echo "** building without S3 support"; \
|
||||
|
|
17
Setup.hs
Normal file
17
Setup.hs
Normal file
|
@ -0,0 +1,17 @@
|
|||
{- cabal setup file -}
|
||||
|
||||
import Distribution.Simple
|
||||
import System.Cmd
|
||||
|
||||
main = defaultMainWithHooks simpleUserHooks {
|
||||
preConf = makeSources,
|
||||
postClean = makeClean
|
||||
}
|
||||
|
||||
makeSources _ _ = do
|
||||
system "make sources"
|
||||
return (Nothing, [])
|
||||
|
||||
makeClean _ _ _ _ = do
|
||||
system "make clean"
|
||||
return ()
|
14
configure.hs
14
configure.hs
|
@ -56,12 +56,24 @@ unicodeFilePath = do
|
|||
{- Pulls package version out of the changelog. -}
|
||||
getVersion :: Test
|
||||
getVersion = do
|
||||
changelog <- readFile "debian/changelog"
|
||||
changelog <- readFile "CHANGELOG"
|
||||
let verline = head $ lines changelog
|
||||
let version = middle (words verline !! 1)
|
||||
|
||||
-- Replace Version field in cabal file, so I don't have to maintain
|
||||
-- the version there too.
|
||||
cabal <- readFile cabalfile
|
||||
writeFile tmpcabalfile $ unlines $ map (setversion version) $ lines cabal
|
||||
renameFile tmpcabalfile cabalfile
|
||||
|
||||
return $ Config "packageversion" (StringConfig version)
|
||||
where
|
||||
middle s = drop 1 $ take (length s - 1) s
|
||||
cabalfile = "git-annex.cabal"
|
||||
tmpcabalfile = cabalfile++".tmp"
|
||||
setversion version s
|
||||
| "Version:" `isPrefixOf` s = "Version: " ++ version
|
||||
| otherwise = s
|
||||
|
||||
setup :: IO ()
|
||||
setup = do
|
||||
|
|
4
debian/changelog
vendored
4
debian/changelog
vendored
|
@ -10,6 +10,10 @@ git-annex (0.20110611) UNRELEASED; urgency=low
|
|||
* git-union-merge: New git subcommand, that does a generic union merge
|
||||
operation, and operates efficiently without touching the working tree.
|
||||
* --force will cause add, etc, to operate on ignored files.
|
||||
* cabal can now be used to build git-annex. This is substantially
|
||||
slower than using make, does not build or install documentation,
|
||||
does not run the test suite, and is not particularly recommended,
|
||||
but could be useful to some.
|
||||
|
||||
-- Joey Hess <joeyh@debian.org> Mon, 13 Jun 2011 19:53:24 -0400
|
||||
|
||||
|
|
|
@ -32,3 +32,10 @@ To build and use git-annex, you will need:
|
|||
* [ikiwiki](http://ikiwiki.info) (optional; used to build the docs)
|
||||
|
||||
Then just [[download]] git-annex and run: `make; make install`
|
||||
|
||||
## Using cabal
|
||||
|
||||
As a haskell package, git-annex can be built using cabal. For example:
|
||||
|
||||
cabal configure
|
||||
cabal install --bindir=$HOME/bin
|
||||
|
|
|
@ -1,8 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://peter-simons.myopenid.com/"
|
||||
ip="84.189.1.247"
|
||||
subject="Why isn't this package built with Cabal?"
|
||||
date="2011-03-23T11:31:06Z"
|
||||
content="""
|
||||
It would be a lot easier to compile this package, if it had a Cabal file to describe the build; especially the build-time dependencies. Why isn't Cabal used?
|
||||
"""]]
|
|
@ -1,17 +0,0 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joey.kitenet.net/"
|
||||
nickname="joey"
|
||||
subject="comment 2"
|
||||
date="2011-03-23T15:18:29Z"
|
||||
content="""
|
||||
Because I haven't learned Cabal yet.
|
||||
|
||||
But also because I've had bad experiences with both a) tying a particular program to a particular language's pet build system and then having to add ugliness when I later need to do something in the build that has nothing to do with that language and b) as a user, needing to deal with the pet build systems of languages when I just need to make some small change to the build process that is trivial in a Makefile.
|
||||
|
||||
With that said, I do have a configure program written in Haskell, so at least it doesn't use autotools. :)
|
||||
|
||||
Update: I did try using cabal, but git-annex includes 3 programs, and they
|
||||
all link to a lot of git-annex modules, and cabal wanted to build nearly
|
||||
every module 3 times, which was too slow for me and I could not find a way
|
||||
around.
|
||||
"""]]
|
49
git-annex.cabal
Normal file
49
git-annex.cabal
Normal file
|
@ -0,0 +1,49 @@
|
|||
Name: git-annex
|
||||
Version: 0.20110611
|
||||
Cabal-Version: >= 1.2
|
||||
License: GPL
|
||||
Maintainer: Joey Hess <joey@kitenet.net>
|
||||
Author: Joey Hess
|
||||
Stability: Stable
|
||||
Copyright: 2010-2011 Joey Hess
|
||||
License-File: GPL
|
||||
Extra-Source-Files:
|
||||
Homepage: http://git-annex.branchable.com/
|
||||
Build-type: Custom
|
||||
Category: Utility
|
||||
Synopsis: manage files with git, without checking their contents into git
|
||||
Description:
|
||||
git-annex allows managing files with git, without checking the file
|
||||
contents into git. While that may seem paradoxical, it is useful when
|
||||
dealing with files larger than git can currently easily handle, whether due
|
||||
to limitations in memory, checksumming time, or disk space.
|
||||
.
|
||||
Even without file content tracking, being able to manage files with git,
|
||||
move files around and delete files with versioned directory trees, and use
|
||||
branches and distributed clones, are all very handy reasons to use git. And
|
||||
annexed files can co-exist in the same git repository with regularly
|
||||
versioned files, which is convenient for maintaining documents, Makefiles,
|
||||
etc that are associated with annexed files but that benefit from full
|
||||
revision control.
|
||||
|
||||
Executable git-annex
|
||||
Main-Is: git-annex.hs
|
||||
GHC-Options: -O2
|
||||
Build-Depends: haskell98, base, MissingH, hslogger, directory, filepath,
|
||||
unix, containers, utf8-string, network, mtl, bytestring, old-locale, time,
|
||||
pcre-light, extensible-exceptions, dataenc, SHA, process, hS3
|
||||
|
||||
Executable git-annex-shell
|
||||
Main-Is: git-annex-shell.hs
|
||||
GHC-Options: -O2
|
||||
Build-Depends: haskell98, base, MissingH, hslogger, directory, filepath,
|
||||
unix, containers, utf8-string, network, mtl, bytestring, old-locale, time,
|
||||
pcre-light, extensible-exceptions, dataenc, SHA, process, hS3
|
||||
|
||||
Executable git-union-merge
|
||||
Main-Is: git-union-merge.hs
|
||||
GHC-Options: -O2
|
||||
|
||||
source-repository head
|
||||
type: git
|
||||
location: git://git-annex.branchable.com/
|
Loading…
Reference in a new issue