1. 11 May, 2018 2 commits
  2. 10 May, 2018 2 commits
  3. 09 May, 2018 2 commits
  4. 08 May, 2018 4 commits
  5. 07 May, 2018 3 commits
  6. 02 May, 2018 2 commits
    • Brad King's avatar
      Merge branch 'ctest-libuv-linux-sparc64' into release-3.11 · 5089d950
      Brad King authored
      Merge-request: !2029
    • Brad King's avatar
      libuv: linux/sparc64: use fcntl to set and clear O_NONBLOCK · 1c22fdf3
      Brad King authored
      Upstream libuv commits:
      * node-v0.6.0~28 (linux: use ioctl(FIONBIO) to set O_NONBLOCK, saves a syscall, 2011-10-29)
      * v1.11.0~11 (unix: use async-signal safe functions between fork and exec, 2016-12-12)
      left an asymmetry in the way O_NONBLOCK is set and cleared.  Normally
      ioctl/FIONBIO is used for both.  However, uv_spawn uses fcntl/O_NONBLOCK
      to clear O_NONBLOCK between fork and exec.  This fails on Linux/sparc64
      where setting via ioctl/FIONBIO actually sets two bits (in O_NDELAY)
      that cause clearing via fcntl/O_NONBLOCK to be silently ignored (though
      clearing via ioctl/FIONBIO or fcntl/O_NDELAY works).
      Since CMake commit v3.11.0-rc1~117^2 (CTest: Re-implement test process
      handling using libuv, 2017-12-10), CTest uses libuv.  On Linux/sparc64
      child processes have been started with non-blocking output pipes.  This
      can lead to write errors or lost output from children not prepared to
      deal with `EAGAIN` on stdout or stderr.
      Fix this for now by switching libuv back to fcntl/O_NONBLOCK to set and
      clear O_NONBLOCK when compiled on Linux/sparc64.
      LibUV-Issue: 1830
      Fixes: #17941
  7. 30 Apr, 2018 2 commits
  8. 27 Apr, 2018 2 commits
  9. 26 Apr, 2018 2 commits
    • Brad King's avatar
      Merge branch 'backport-ninja-issue-17942' into release-3.11 · a92ee4e3
      Brad King authored
      Merge-request: !2010
    • Brad King's avatar
      Ninja: Do not add empty custom command for file(GENERATE) outputs · 0826c201
      Brad King authored
      Internally we mark `file(GENERATE)` outputs as `GENERATED` in order
      to tell custom command dependency tracing logic not to expect the
      files to exist on disk yet.  This is because we do not generate the
      files until after that tracing is done.
      The Ninja generator also interprets the `GENERATED` property to mean
      that it is expected that some build rule will generate the file if
      another build rule depends on it.  If the generator does not know of a
      custom command that generates the file then it adds an empty one so that
      the `ninja` build tool does not complain about a dependency on a file
      that does not exist and has no rule to generate it.  However, this step
      is not necessary for `file(GENERATE)` outputs because there is no build
      rule to generate them and they will exist before `ninja` runs.
      Add an additional `__CMAKE_GENERATED_BY_CMAKE` property internally to
      tell the Ninja generator that a `GENERATED` file will exist before the
      build starts and is not expected to have a build rule producing it.
      Fixes: #17942
  10. 25 Apr, 2018 2 commits
  11. 24 Apr, 2018 5 commits
  12. 18 Apr, 2018 2 commits
  13. 17 Apr, 2018 3 commits
  14. 16 Apr, 2018 6 commits
  15. 13 Apr, 2018 1 commit