Skip to content
  • Fraser Tweedale's avatar
    afde4276
    fix executablePath test for NetBSD · afde4276
    Fraser Tweedale authored and Marge Bot's avatar Marge Bot committed
    executablePath support for NetBSD was added in
    a172be07, but the test was not
    updated.
    
    Update the test so that it works for NetBSD.  This requires handling
    some quirks:
    
    - The result of getExecutablePath could include "./" segments.
      Therefore use System.FilePath.equalFilePath to compare paths.
    
    - The sysctl(2) call returns the original executable name even after
      it was deleted.  Add `canQueryAfterDelete :: [FilePath]` and
      adjust expectations for the post-delete query accordingly.
    
    Also add a note to the `executablePath` haddock to advise that
    NetBSD behaves differently from other OSes when the file has been
    deleted.
    
    Also accept a decrease in memory usage for T16875.  On Windows, the
    metric is -2.2% of baseline, just outside the allowed ±2%.  I don't
    see how this commit could have influenced this metric, so I suppose
    it's something in the CI environment.
    
    Metric Decrease:
        T16875
    afde4276
    fix executablePath test for NetBSD
    Fraser Tweedale authored and Marge Bot's avatar Marge Bot committed
    executablePath support for NetBSD was added in
    a172be07, but the test was not
    updated.
    
    Update the test so that it works for NetBSD.  This requires handling
    some quirks:
    
    - The result of getExecutablePath could include "./" segments.
      Therefore use System.FilePath.equalFilePath to compare paths.
    
    - The sysctl(2) call returns the original executable name even after
      it was deleted.  Add `canQueryAfterDelete :: [FilePath]` and
      adjust expectations for the post-delete query accordingly.
    
    Also add a note to the `executablePath` haddock to advise that
    NetBSD behaves differently from other OSes when the file has been
    deleted.
    
    Also accept a decrease in memory usage for T16875.  On Windows, the
    metric is -2.2% of baseline, just outside the allowed ±2%.  I don't
    see how this commit could have influenced this metric, so I suppose
    it's something in the CI environment.
    
    Metric Decrease:
        T16875
Loading