Skip to content
Snippets Groups Projects
  1. May 17, 2018
  2. May 15, 2018
  3. May 14, 2018
  4. May 11, 2018
  5. May 10, 2018
  6. May 09, 2018
  7. May 08, 2018
  8. May 07, 2018
  9. May 02, 2018
    • Brad King's avatar
      Merge branch 'ctest-libuv-linux-sparc64' into release-3.11 · 5089d950
      Brad King authored
      Merge-request: !2029
      5089d950
    • 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
      1c22fdf3
  10. Apr 30, 2018
  11. Apr 27, 2018
  12. Apr 26, 2018
    • Brad King's avatar
      Merge branch 'backport-ninja-issue-17942' into release-3.11 · a92ee4e3
      Brad King authored
      Merge-request: !2010
      a92ee4e3
    • 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
      0826c201
  13. Apr 25, 2018
  14. Apr 24, 2018
  15. Apr 18, 2018
  16. Apr 17, 2018
Loading