The current use of the 'Fast' and 'Production' flags is both inconsistent and
redundant. It's inconsistent, because users are allowed to specify both '-fFast
-fProduction' at the same time -- thereby enabling two contradicting features.
The flags are redundant, because Cabal allows users to specify '-O0' at
configure time, which is essentially the same as '-fFast'. Since 'Production'
is just the opposite of 'Fast', this means that neither flag is needed.
I have seen some other programs do this, and think it's pretty cool. Means
you can test wherever it's deployed, as well as at build time.
My other reason for doing it is less happy. Cabal's handling of test suites
sucks, requiring duplicated info, and even when that's done, it fails to
preprocess hsc files here. Building it in avoids that and avoids having
to explicitly tell cabal to enable test suites, which would then make it
link the test executable every time, which is unnecessarily slow.
This also has the benefit that now "make fast test" does a max speed build
and tests it.
Stopped checking the assistant flag for flags like webapp and xmpp,
because cabal disables the assistant if the other flag's dependencies
cannot be satisfied.
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.
The expensive scan uses lookupFile, but in direct mode, that doesn't work
for files that are present. So the scan was not finding things that are
present that need to be uploaded. (It did find things not present that
needed to be downloaded.)
Now lookupFile also works in direct mode. Note that it still prefers
symlinks on disk to info committed to git, in direct mode. This is
necessary to make things like Assistant.Threads.Watcher.onAddSymlink
work correctly, when given a new symlink not yet checked into git (or
replacing a file checked into git).
Fixes the following test failure:
Preprocessing test suite 'test' for git-annex-3.20121211...
Remote/Git.hs:42:8:
Could not find module `Control.Concurrent.MSampleVar'
It is a member of the hidden package `SafeSemaphore-0.9.0'.
Perhaps you need to add `SafeSemaphore' to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
For no apparent reason, this version removes all useful instances of
ToJavaScript, leavind behind only an instance for Aeson.Value. Argh. Pissed
off at this arbitrary breaking change, and seriously considering dropping
this library.
This adds a dep on haskell's async library, but since that's been
added to the recent haskell platform release, it should not be
much hardship to my poor long-suffering library chasing users.
Adjust build deps to ensure that only a fixed version of the library will
be used.
Also, removed the bound thread stuff, which I now think was (probably)
a red herring.
MountWatcher can't do this, because it uses the session dbus,
and won't have access to the new DBUS_SESSION_BUS_ADDRESS if a new session
is started.
Bumped dbus library version, FD leak in it is fixed.
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.
For now, when dbus goes away, the assistant keeps running but does not fall
back or reconnect. To do so needs more changes to the DBus library; in
particular a connectSessionWith and connectSystemWith to let me specify
my own clientThreadRunner.
Seems cabal defaults to trying to satisfy both flags, which cannot works,
and does not fall back to only selecting one, as hoped. While users could
manually specify flags, I don't want to require that to build, so let's
just require the newer yesod version when building with cabal.
Old 1.0.1 version is still supported as well. Cabal autodetects
which version is available, but in the Makefile, WITH_OLD_YESOD
has to be configured appropriately.
I have not squashed all the $newline warnings with the new Yesod.
They should go away eventually anyway as Yesod moves past that transition.
