This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 23 Sep, 2016 1 commit
    • Duncan Coutts's avatar
      New Rebuild monad utils and use in ProjectPlanning · c7d55c3c
      Duncan Coutts authored
      Monitored variants of createDirectory and getDirectoryContents.
      Define thee wrappers in the RebuildMonad module so we have fewer
      open-coded tricky monitorFiles calls.
      
      In particular replace a glob monitor on the content of the store with a
      monitor on the store directory itself. This is valid based on the
      behaviour of directory mtimes, which is specified by posix and we have a
      sanity check for it in the unit tests.
      c7d55c3c
  2. 20 Apr, 2016 1 commit
  3. 17 Apr, 2016 2 commits
    • Duncan Coutts's avatar
      matchFileGlob should only monitor for existence · ed1cc2fe
      Duncan Coutts authored
      Since the matchFileGlob function returns names of files and not content,
      actions using it don't actually depend on the content, so it's more
      consistent not to monitor the content.
      
      In particular, following Edward's recent fix, the code that reads the
      package cabal files already monitors the content. This is the
      appropriate separation of concerns, the code that finds the .cabal files
      monitors the search glob for file existence, while the code that reads
      the .cabal files monitors the file content.
      ed1cc2fe
    • Duncan Coutts's avatar
      Refactor the Rebuild monad to keep file root in Reader env · bba5a817
      Duncan Coutts authored
      Fixes #3323 and #3324, ensuring we monitor the project Cabal files.
      Original fix by Edward Z. Yang. The approach in this patch is to fix an
      underlying problem. Subsequent patches use a more consistent approach to
      the monitoring as suggested by Edward.
      
      The motivating example is:
      
        matches <- matchFileGlob dirname glob
      
      where matchFileGlob is defined in the RebuildMonad module as
      
      matchFileGlob root glob = do
          monitorFiles [monitorFileGlob glob]
          liftIO $ Glob.matchFileGlob root glob
      
      This usage is wrong because the root used to match the glob is not the
      same as the root that will be used later when checking the file monitor
      for changes. You can see this is suspicious because the declaration of
      the monitor does not take an root dir paramater but the immediate
      matching does. That's because the root for the monitors is specified
      when we do the rerunIfChanged to check the monitor.
      
      So the only correct usage involves passing in the correct root. This is
      a ripe source of bugs. So this refactoring moves the root into the
      Rebuild monad directly, so the example becomes:
      
        matches <- matchFileGlob glob
      
      The root is implicit, so you can't accidentally pick a different root
      for the immediate match vs the later monitor check. Of course the root
      still matters, but if you get that wrong you'll notice immediately
      because you will not get the match results you were expecting.
      
      So the root is now passed in with runRebuild, not with rerunIfChanged.
      
      Also change the incorrect use of matchFileGlob. This use case now
      relies on the adjusted representation of glob roots, using
      FilePath.splitDrive to obtain the root (if any).
      bba5a817
  4. 27 Mar, 2016 1 commit
    • Duncan Coutts's avatar
      Extend file globs and file glob monitors · 2d569609
      Duncan Coutts authored
      File globs can now be absolute, e.g. starting with / or c:\
      Also allow homedir relative, ie ~/
      
      Globs can also have a trailing slash, in which case they only match
      directories, not files.
      
      Previously whether globs could match dirs was not totally consistent.
      The matchFileGlob would match dirs, but the file monitor globs would
      not. The file monitor globs can now match dirs (or with a trailing
      slash, only match dirs). File monitors now also detect changes in the
      file type, ie switching from file to dir or the other way around.
      
      The file monitor are now pretty consistent between single file monitors
      and globs monitors. They now have equivalent capabilities and share
      code. For a single file or for a glob we can now control what we
      monitor if the path is a file or a dir. In both cases we can monitor
      mere existence, non-existence or modification time. For files we can
      additionally monitor content hash.
      
      File monitors now also detect changes in the file type, ie switching
      from file to dir or the other way around.
      
      New tests cover all these new file monitor cases. There are also new
      tests for glob syntax, covering printing/parsing round trips.
      
      (cherry picked from commit f6c1e71c)
      2d569609
  5. 17 Mar, 2016 1 commit
    • Duncan Coutts's avatar
      Add a couple glob utils · 5f6614a6
      Duncan Coutts authored
      One for testing if globs are trivial, as in they're constant strings
      without the possibility of matching more than one thing. This can help
      with making better error messages.
      
      Another util for matching file globs in the rebuild monad, and
      automatically monitoring the glob.
      
      (cherry picked from commit 4365bcb1)
      5f6614a6
  6. 03 Mar, 2016 1 commit
  7. 19 Feb, 2016 1 commit
    • Duncan Coutts's avatar
      FileMonitor: handle changes during an update action · a15d0d77
      Duncan Coutts authored
      If we take the snapshot after the action has completed then we have a
      problem. The problem is that files might have changed while the action
      was running but /after/ the action read them. If we take the snapshot
      after the action completes then we will miss these changes.
      
      The solution is to record a timestamp before beginning execution of the
      action and then we make the conservative assumption that any file that
      has changed since then has already changed, ie the file monitor state
      for these files will be such that checkFileMonitorChanged will report
      that they have changed.
      
      Makes use of this in the Rebuild monad so everything using this will get
      the feature for free. Also adds a test.
      
      Changed the representation of files that have already changed by the
      time we take the snapshot. We had two extra constructor, but now instead
      we represent it with the normal constructors but with a Maybe ModTime.
      The reason is that it's easier to extend to the globbing case.
      a15d0d77
  8. 07 Feb, 2016 1 commit
    • Duncan Coutts's avatar
      New infrastructure for tracking changes in files and values · f35e05df
      Duncan Coutts authored
      A FileMonitor is an abstraction for monitoring the status of files,
      as well as changes in an in-memory value. Files can be tracked by file
      modification time, or mod time plus content. We can also track files
      that are expected not to exist (to help implement search paths). We can
      also have file globs.
      
      The abstraction is useful for re-running actions when input files or
      values change. This pattern is captured by the Rebuild monad.
      
      This adds a dependency on the hashable package (used by
      unordered-containers). If this is a problem we can extract just the hash
      function we need.
      
      This is not used yet, so there's a temporary import just to make sure it
      gets compiled.
      f35e05df