Skip to content
Snippets Groups Projects
  1. Nov 02, 2018
  2. Nov 01, 2018
  3. Oct 31, 2018
    • Brad King's avatar
      Merge branch 'backport-fix-custom-target-with-csharp' into release-3.12 · 609bdd12
      Brad King authored
      Merge-request: !2549
      609bdd12
    • Brad King's avatar
      CSharp: Fix regression in VS project type selection for custom target · 1acd1c2b
      Brad King authored
      A target created by `add_custom_target` should always be a `.vcxproj`
      file even if it has `.cs` sources involved in custom commands and such.
      The latter case was broken by refactoring in commit v3.12.0-rc1~160^2~7
      (remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget,
      2018-03-19).  The reason is that the `HasLanguage` method added by
      commit v3.12.0-rc1~239^2~6 (cmGeneratorTarget: add HasLanguage() as
      wrapper for GetLanguages(), 2018-03-19) does not check the target type
      and so is not a suitable check for deciding the project file extension.
      
      The `HasLanguage` method was an attempt at an abstraction that turns
      out not to work very well.  Replace it with a dedicated `IsCSharpOnly`
      method that considers the target type, sources, and non-transitive
      `LINKER_LANGUAGE`.
      
      Fixes: #18515
      1acd1c2b
  4. Oct 29, 2018
  5. Oct 24, 2018
  6. Oct 10, 2018
  7. Oct 05, 2018
  8. Oct 03, 2018
  9. Oct 02, 2018
    • Brad King's avatar
      Merge branch 'fix-csharp-target-type' into release-3.12 · 7787fb6e
      Brad King authored
      Merge-request: !2427
      7787fb6e
    • Brad King's avatar
      CSharp: Fix regression in VS project type selection · 375b420f
      Brad King authored
      A that target contains only `.cs` sources should be generated as a
      `.csproj` project even if it links to non-CSharp static libraries.
      The latter case was broken by refactoring in commit v3.12.0-rc1~160^2~7
      (remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget,
      2018-03-19).  The reason is that the `HasLanguage` method added by
      commit v3.12.0-rc1~239^2~6 (cmGeneratorTarget: add HasLanguage() as
      wrapper for GetLanguages(), 2018-03-19) enforces its "exclusive" check
      on the combined set of source file languages and the link language.
      To restore the original `TargetIsCSharpOnly` semantics, update
      `HasLanguage` to enforce exclusiveness only on the list of sources.
      
      Fixes: #18239
      375b420f
    • Brad King's avatar
      VS: Fix CSharp flag selection when linking to a static C++ library · 8b21aa0a
      Brad King authored
      When a CSharp target links to a static C++ library, CMake will compute
      the link language as C++ instead of CSharp.  That may be incorrect and
      needs further investigation, but it does not affect how VS drives C#
      linking.  However, it does break our flag language selection logic
      and causes C++ flags to be used for CSharp.  In particular, this
      drops the `-platform:x86` flag on 32-bit builds.
      
      Fix this by always selecting the CSharp flags when generating a
      `.csproj` project type.
      
      Issue: #18239
      8b21aa0a
  10. Oct 01, 2018
    • Brad King's avatar
      Merge branch 'libuv-gnu-hurd' into release-3.12 · 518c5060
      Brad King authored
      Merge-request: !2422
      518c5060
    • Brad King's avatar
      libuv: do not require PATH_MAX to be defined · 3c0bfb59
      Brad King authored
      Some platforms (e.g. GNU/Hurd) do not define PATH_MAX.  Add a few other
      variants and a fallback constant.  Also use alternatives where possible:
      
      * For readlink(), use lstat() to read the length of the link first.
        If it is not a symlink, report EINVAL before trying to allocate.
        If the size reports as zero, fall back one of the PATH_MAX variants.
      
      * For realpath(), POSIX 2008 allows us to pass a NULL buffer
        to tell it to malloc() internally.
      
      This patch was inspired by downstream patches in Debian packaging
      for issues 897061 and 909011.
      
      Issue: #18337
      3c0bfb59
  11. Sep 26, 2018
  12. Sep 19, 2018
  13. Sep 11, 2018
  14. Sep 10, 2018
    • Brad King's avatar
      Merge branch 'FindMPI-restore-flags-string' into release-3.12 · e0e56abe
      Brad King authored
      Merge-request: !2368
      e0e56abe
    • Brad King's avatar
      Merge branch 'fix-ctest_start-track' into release-3.12 · 3eda5cdd
      Brad King authored
      Merge-request: !2366
      3eda5cdd
    • Brad King's avatar
      FindMPI: Restore MPI_<LANG>_COMPILE_FLAGS as a command-line string · e374b9f1
      Brad King authored
      Refactoring in commit v3.10.0-rc1~103^2~2 (FindMPI: Modernization from
      ground up, 2017-04-25) accidentally left this variable set as a copy of
      the `;`-list in `MPI_<LANG>_COMPILE_OPTIONS`, but the flags variable is
      documented as a command-line string.  Restore it now.
      
      Fixes: #18349
      e374b9f1
    • Kyle Edwards's avatar
      CTest: Fix regression in ctest_start() · 09f0325e
      Kyle Edwards authored
      The format for the TAG file was changed in 3.12, and the way it was
      read caused a regression which changed how the track was decided. This
      commit fixes the regression.
      
      Fixes #18347.
      09f0325e
    • Brad King's avatar
      Merge branch 'ctest-fix-test-load' into release-3.12 · 68f2b471
      Brad King authored
      Merge-request: !2362
      68f2b471
    • Brad King's avatar
      CTest: Fix --test-load regression · 292ec157
      Brad King authored
      The `ctest --test-load` option is implemented in `StartNextTests` by not
      starting any tests when the load is too high and instead sleeping and
      then returning.  Prior to commit v3.11.0-rc1~117^2 (CTest: Re-implement
      test process handling using libuv, 2017-12-10) our outer loop in
      `RunTests` would immediately call `StartNextTests` again.  However, now
      the `uv_run` loop may simply terminate if there are no tests running
      because no events are left pending.
      
      Fix this by converting the sleep in `StartNextTests` into a libuv timer
      that it starts instead.  This avoids leaving `uv_run` with no pending
      events.  In the case that there are other running tests this also allows
      CTest to detect when they finish even if it during the wait period where
      we previously slept.
      
      This regression was not caught by the test suite because it only
      verified that we do not start new tests when the load was too high and
      not that we proceed to start tests when the load drops.  Revise the test
      suite to cover both.
      
      Fixes: #18338
      292ec157
  15. Sep 07, 2018
  16. Sep 05, 2018
Loading