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.
The only thing lost is ./ghci
Speed: make fast used to take 20 seconds here, when rebuilding from
touching Command/Unused.hs. With cabal, it's 29 seconds.
I need to clean up the path to hasktags. Ideally by packaging it in Debian.
Not using ghci's own tags generation because it falls over on pre-compiled
files.
Converted from using c2hs to using hsc2hs, just because other code
in git-annex uses hsc2hs.
Various cleanups.
This code is LGPLed, so I had to include that licence.
Add link CONTRIBUTING -> doc/contributing.mdwn, so that it's easy to
find (many files in doc/).
Add .dir-locals.el to .gitignore, now that it's no longer versioned.
The CONTRIBUTING file gives a reference to a page on the Emacs wiki
that shows how to set up a .dir-locals.el that sets up tabs for
indentation. I updated the wiki page to include the
`(highlight-regexp "^ *")` part, which had been the hardest to
discover.
The existing `sed | find | perl` hack in the Makefile was not
including the man pages in the generated git-annex.cabal. I couldn't
figure out why it didn't work; running the `find | perl` part of the
command *did* list the man pages ...
So, I set up a new hack. It produces a cleaner .cabal file and
includes the man pages in the sdist. I changed git-annex.cabal and
its generation as follows:
- git-annex.cabal is now generated by a here document in
git-annex.cabal.template.sh. The here document has inline file list
insertion, whereas before the file lists were inserted with sed.
- The 'Extra-Source-Files:' field now only includes the non-source
files: the man pages, plain text documentation, and license.
- The source dependencies are now listed in 'Other-Modules' sections
in the 'Executable' and 'Test-Suite' sections. The list of
dependencies is generated by `gen-other-modules.sh`.
- The ./debian and ./doc are no longer included in the sdist package.
These were not installed anywhere by `cabal install`. A user that
wants them could clone the git repo.
Running the tests with cabal is not yet working, i.e.
cabal configure --enable-tests && cabal build && cabal test
and
cabal install --enable-tests
fail to find Utility.Touch. However, I did not break this: it doesn't
work for the git-annex package on Hackage either. Next step is to
figure out how to deal with HSC in cabal ... or not bother, because
`make test` works. I'm worried this is a cabal bug.
To test building from sdist, I've been running
cd ../.. ; cabal sdist ; cd dist ; tar xf git-annex-3.20120605.tar.gz && cd git-annex-3.20120605 && rm -fr /tmp/git-annex && cabal install --prefix=/tmp/git-annex && tree -A /tmp/git-annex
in the dist directory. Using `cabal-dev install` is a better test,
but is very slow.
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 is a new git subcommand, that does a generic union merge operation
between two refs, storing the result in a branch. It operates efficiently
without touching the working tree. It does need to write out a temporary
index file, and may need to write out some other temp files as well.
This could be useful for anything that stores data in a branch,
and needs to merge changes into that branch without actually checking the
branch out. Since conflict handling can't be done without a working copy,
the merge type is always a union merge, which is fine for data stored in
log format (as git-annex does), or in non-conflicting files
(as pristine-tar does).
This probably belongs in git proper, but it will live in git-annex for now.
---
Plan is to move .git-annex/ to a git-annex branch, and use git-union-merge
to handle merging changes when pulling from remotes.
Some preliminary benchmarking using real .git-annex/ data indicates
that it's quite fast, except for the "git add" call, which is as slow
as "git add" tends to be with a big index.
When adding files to the annex, the symlinks pointing at the annexed
content are made to have the same mtime as the original file. While git
does not preserve that information, this allows a tool like metastore to be
used with annexed files.
The option cause it to always build to build/Main.o, no matter what
binary it was building. This caused extra work, and in some cases,
could cause the wrong code to be put into the final binary.
