1. 03 Oct, 2017 2 commits
  2. 27 Sep, 2017 1 commit
  3. 25 Sep, 2017 1 commit
  4. 21 Sep, 2017 1 commit
  5. 18 Sep, 2017 1 commit
    • comicfans's avatar
      VS: Fix MANIFESTUAC link flag map to .vcxproj elements · 3232f84c
      comicfans authored and Brad King's avatar Brad King committed
      Add special parsing of the flags given in `/MANIFESTUAC:"..."` in order
      to map them correctly to `.vcxproj` elements.
      Keep the old incorrect flag table entries for `uiAccess` and `level`
      flags for compatibility even though they do not really exist.
      Fixes: #16563
  6. 15 Sep, 2017 1 commit
  7. 12 Sep, 2017 1 commit
  8. 11 Sep, 2017 1 commit
    • SSE4's avatar
      VS: Update support for LLVM-vs* toolsets from LLVM 5.0 · 8a4755ca
      SSE4 authored and Brad King's avatar Brad King committed
      Revert commit v3.7.0-rc1~25^2 (VS: Recognize VS/LLVM toolset names as
      Clang, 2016-09-28).  Since at least LLVM 5.0 the VS integration of the
      LLVM toolchain now mimics cl and accepts MSVC-style command-line
      arguments (unlike Microsoft Clang/C2).
      Fixes: #17193, #17235
  9. 05 Sep, 2017 1 commit
    • Michael Stürmer's avatar
      VS: Do not reference output assemblies if not possible for CSharp target · 7e57e6ae
      Michael Stürmer authored and Brad King's avatar Brad King committed
      Since commit v3.9.0-rc4~4^2 (Vs: allow CSharp targets to be linked to
      CXX targets, 2017-06-20) CSharp targets get `ProjectReference` entries
      to their dependencies.  This causes VS to also reference the
      dependency's output assembly by default, which is incorrect for
      non-managed targets.
      Fix this by setting `ReferenceOutputAssembly` to `false` for targets
      that can't provide output assemblies.  Unmanaged C++ targets (shared
      libs & executables) can still be referenced and a warning will be shown
      in the IDE but the build will not break anymore.
      Fixes: #17172
  10. 04 Sep, 2017 1 commit
  11. 30 Aug, 2017 1 commit
  12. 24 Aug, 2017 1 commit
  13. 23 Aug, 2017 1 commit
  14. 17 Aug, 2017 1 commit
  15. 12 Jul, 2017 1 commit
  16. 28 Jun, 2017 1 commit
    • Brad King's avatar
      VS: Fix GenerateDebugInformation values for v140 and v141 toolsets · ae44496e
      Brad King authored
      When VS 2015 was first released, its new v140 toolset came with a
      `link.xml` file that changed the `GenerateDebugInformation` boolean
      (`false` and `true`) value from earlier toolsets to an enumeration
      consisting of the possible values `No`, `Debug`, and `DebugFastLink`.
      We first adapted to this in commit v3.4.2~2^2 (VS: Fix VS 2015 .vcxproj
      file value for GenerateDebugInformation, 2016-01-08), but that broke
      older toolsets that still expected the boolean.  Then commit
      v3.6.0-rc1~295^2~1 (VS: Fix VS 2015 .vcxproj debug setting for older
      toolsets, 2016-02-24) added a hack to fix up the value based on the
      toolset in use.  Several follow-up commits fixed this for more older
      toolsets because our flag table was at the time based on the generator
      in use rather than the toolset in use.
      Since commit v3.8.0-rc1~396^2 (VS: Choose flag map based on the toolset
      name, 2016-10-17) we use a flag table based on the toolset, so the fixup
      hack should not be needed.  We had to keep it around only due to our
      default value for GenerateDebugInformation (`false` or `No`) still being
      based on the generator instead of the toolset.
      A VS 2015 update was released that changed the v140 toolset `link.xml`
      file back to using `false` and `true` for the `GenerateDebugInformation`
      enumeration variants previously known as `No` and `Debug`.  In order to
      know which pair to use, we need to parse the `link.xml` file for the
      current toolset.
      Switch back to using `false` and `true` unconditionally in our
      `GenerateDebugInformation` flag table entries and default value.  With
      that plus the toolset-based flag table, we now get incorrect values for
      `GenerateDebugInformation` only when using a v140 toolset from an older
      VS 2015 installation.  Detect this case by parsing `link.xml` and add
      special logic to convert `false` and `true` to `No` and `Debug` to
      satisfy the older toolset specification.
      Inspired-by: default avatarIan Hojnicki <nullref@live.com>
      Fixes: #17020
  17. 27 Jun, 2017 1 commit
    • Brad King's avatar
      VS: Fix support for nvcc flags not in our flag table · bbc1f364
      Brad King authored
      The change in commit v3.9.0-rc4~3^2 (VS: Improve workaround for CUDA
      -Xcompiler placement bug, 2017-06-21) accidentally appended to the
      `AdditionalOptions` as if it were a `;`-separated list, but it is
      actually a command-line string.  Append with a space instead.
      While at it, fix the same problem for the `AdditionalOptions` added to
      `CudaLink` by commit v3.9.0-rc3~1^2 (CUDA: When linking device code
      suppress CUDA 8.0+ deprecation warnings, 2017-06-09).
      Fixes: #17008
  18. 22 Jun, 2017 5 commits
  19. 21 Jun, 2017 3 commits
    • Brad King's avatar
      VS: Improve workaround for CUDA -Xcompiler placement bug · 3b754215
      Brad King authored
      In commit v3.9.0-rc1~431^2~6 (VS: Place CUDA host compiler options in
      proper project file fields, 2017-03-07) we worked around a bug in the
      CUDA VS integration by dropping `AdditionalCompilerOptions`.  However,
      this silently drops `-Xcompiler=` options given by the user that don't
      map to one of CudaCompile's dedicated settings.  Improve the workaround
      to instead put the remaining `AdditionalCompilerOptions` into the
      `AdditionalOptions` field behind `-Xcompiler=` ourselves.
    • Brad King's avatar
      VS: Fix target_compile_options for CUDA · f2059585
      Brad King authored
      Fix the VS generator to honor `COMPILE_OPTIONS` for CUDA.  The exclusion
      added by commit v3.9.0-rc1~431^2~7 (VS: Do not pass CUDA compile options
      to C compiler, 2017-03-07) was correct but we need additional logic to
      pass the CUDA compile options to the CUDA compiler.  Also we should
      still pass the CXX or C options to MSVC (ClCompile) when those languages
      are enabled even if the link language is CUDA.
    • Michael Stürmer's avatar
      Vs: allow CSharp targets to be linked to CXX targets · 51865fc6
      Michael Stürmer authored
      Fixes: #16755
  20. 16 Jun, 2017 1 commit
  21. 14 Jun, 2017 1 commit
    • Brad King's avatar
      IPO: Consider support for each language separately · ba247cca
      Brad King authored
      We only define `INTERPROCEDURAL_OPTIMIZATION` behavior for C, CXX, and
      Fortran languages.  Do not try to enable support for other languages.
      Furthermore, each language builds with a different compiler, so check
      for support by CMake and the compiler for each language independently.
      Fixes: #16944
  22. 13 Jun, 2017 3 commits
  23. 30 May, 2017 1 commit
  24. 24 May, 2017 1 commit
  25. 22 May, 2017 1 commit
  26. 09 May, 2017 1 commit
    • Brad King's avatar
      VS: Fix .vcxproj ProjectGuid element case · 776929b3
      Brad King authored
      The `.vcxproj` file format expects `ProjectGuid`, not `ProjectGUID`.
      The latter is expected by `.vcproj` files from VS 2008, so this was
      likely a typo when the VS 2010 generator was first introduced.
      Fixes: #11968
  27. 03 May, 2017 1 commit
  28. 26 Apr, 2017 2 commits
  29. 20 Apr, 2017 2 commits