The type of getModificationTime has changed, leading to some CPP
Support directory 1.2
+1. This is required to have zip-archive build on ghc 7.6.1
Would it not be better to use
instead of introducing a new flag? Then the decision of which directory version to use could be made automatically by cabal, and the code would work either way...
The flag needs to be in the cabal file so we can add time to the package dependencies, unless you prefer to do that unconditionally. cabal will infer the right setting for the flag - the user doesn't need to set it explicitly either way.
I could replace the custom CPP macro with MIN_VERSION_directory if you prefer - I used it because I'm wasn't familiar with MIN_VERSION_xxx and the macro I added mirrored the existing _WINDOWS macro.
I see the point about the time dependency. But can you explain your claim that "cabal will infer the right setting for the flag"? Do you mean that if the user has only the older version of directory installed, cabal will automatically set the flag to use it, rather than pulling in the new version? I didn't know it worked that way.
I'm not entirely sure how cabal decides whether to install new packages or not, but I do know it is happy to select either directory 1.1 or directory 1.2 without any explicit setting of the flag. I guess the existing splitBase flag relies on the same logic.
The docs (http://www.haskell.org/cabal/users-guide/developing-packages.html#configurations) say "By default, Cabal will first try to satisfy dependencies with the default flag value and then, if that is not possible, with the negated value." - so I guess if we want to discourage it from installing the new version, the flag's sense should be switched.