Some systems can get the file modification time with sub-second
granularity. However, Hakyll shaves off the sub-seconds, as defined in
the Binary instance of BinaryTime, which poses a problem because when a
file is checked to see if it was modified in `resourceModified`, it
still contains the sub-seconds. This results in a file (almost) always
being considered as having been modified.
Example:
1. First go around, modification time is 3:45.325. This time is saved
as 3:45.000 (i.e. sub-seconds are shaved off).
2. Second go around, modification time is again read as 3:45.325 and
compared against the stored time, 3:45.000. 3:45.325 is more recent
than 3:45.000, so the file is considered to have been modified.
This change prevents the shaving off of sub-seconds. This will naturally
work on systems that don't support sub-second granularity, as that
'field' will simply appear as all zeros.
Closes#250
On windows, the 'unixFilter' function used window's 'createProcess'
function to create the external process that will filter some String
input. The problem with this is that it is unable to execute batch
stubs (eg. anything created using 'gem install ...') even if its in
$PATH. Anyways a solution to this issue is to execute the batch file
explicitly using 'cmd /c batchfile' but there is no rational way to know
where said batchfile is on the system. My solution is to detect windows
using the System.Info module and then instead of using 'proc' to create
the function, use 'shell' instead which will be able to execute
everything 'proc' can + batch files.
Inspired by: http://www.blaenkdenum.com/posts/the-switch-to-hakyll/#scss
Signed-off-by: Collin J. Doering <rekahsoft@gmail.com>
The old test returns an exit code of 1 whenever the number of
errors is >= 0, which should always be the case. The fix replaces
this with a test whether the number of errors is strictly > 0.
I had to prepend some Rules to global Rules set. This might be possible
to replaced by a correct Store.set call.
I also had to prepend some Compile rules.
