Skip to content
Snippets Groups Projects
  1. Jul 28, 2017
    • Chris Bieneman's avatar
      [CMake] NFC. Add clang-tablegen-targets utility target · db2a5b14
      Chris Bieneman authored
      By creating this target other projects that depend on clang-generated headers (like LLDB) will no longer be order-dependent on Clang being processed by CMake first.
      
      Also, by creating a dummy of this target in ClangConfig.cmake, projects that can build against out-of-tree clang can freely depend on the target without needing to have conditionals for if clang is in-tree or out-of-tree.
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309390 91177308-0d34-0410-b5e6-96231b3b80d8
      db2a5b14
  2. Jul 26, 2017
  3. Jul 23, 2017
  4. Jul 18, 2017
  5. May 23, 2017
  6. May 11, 2017
  7. Apr 04, 2017
  8. Mar 07, 2017
  9. Feb 19, 2017
  10. Feb 13, 2017
  11. Jan 25, 2017
  12. Jan 18, 2017
  13. Jan 10, 2017
  14. Dec 31, 2016
  15. Dec 14, 2016
  16. Nov 17, 2016
  17. Oct 19, 2016
  18. Oct 18, 2016
  19. Sep 22, 2016
  20. Sep 21, 2016
  21. Sep 20, 2016
  22. Sep 16, 2016
    • David L. Jones's avatar
      Simplify Clang's version number configuration in CMake. · 133fae62
      David L. Jones authored
      Currently, the Clang version is computed as follows:
      
       1. LLVM defines major, minor, and patch versions, all statically set. Today,
          these are 4, 0, and 0, respectively.
       2. The static version numbers are combined into PACKAGE_VERSION along with a
          suffix, so the result today looks like "4.0.0svn".
       3. Clang extracts CLANG_VERSION from PACKAGE_VERSION using a regexp. The regexp
          allows the patch level to omitted, and drops any non-digit trailing values.
          Today, this result looks like "4.0.0".
       4. CLANG_VERSION is then split further into CLANG_VERSION_MAJOR and
          CLANG_VERSION_MINOR. Today, these resolve to 4 and 0, respectively.
       5. If CLANG_VERSION matches a regexp with three version components, then
          CLANG_VERSION_PATCHLEVEL is extracted and the CLANG_HAS_VERSION_PATCHLEVEL
          variable is set to 1. Today, these values are 0 and 1, respectively.
       6. The CLANG_VERSION_* variables (and CLANG_HAS_VERSION_PATCHLEVEL) are
          configured into [llvm/tools/clang/]include/clang/Basic/Version.inc
          verbatim by CMake.
       7. In [llvm/tools/clang/]include/clang/Basic/Version.h, macros are defined
          conditionally, based on CLANG_HAS_VERSION_PATCHLEVEL, to compute
          CLANG_VERSION_STRING as either a two- or three-level version number. Today,
          this value is "4.0.0", because despite the patchlevel being 0, it was
          matched by regexp and is thus "HAS"ed by the preprocessor. This string is
          then used wherever Clang's "version" is needed [*].
      
      [*] Including, notably, by compiler-rt, for computing its installation path.
      
      This change collapses steps 2-5 by defaulting Clang to use LLVM's (non-string)
      version components for the Clang version (see [*] for why not PACKAGE_VERSION),
      and collapses steps 6 and 7 by simply writing CLANG_VERSION_STRING into
      Version.inc. The Clang version today always uses the patchlevel form, so the
      collapsed Version.inc does not have logic for a version without a patch level.
      
      Historically speaking, this technique began with the VER file in r82085 (which
      survives in the form of the regexp in #3). The major, minor, and patchlevel
      versions were introduced by r106863 (which remains in #4-6). The VER file itself
      was deleted in favor of the LLVM version number in r106914. On the LLVM side,
      the individual LLVM_VERSION_MAJOR, LLVM_VERSION_MINOR, and PACKAGE_VERSION
      weren't introduced for nearly two more years, until r150405.
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281666 91177308-0d34-0410-b5e6-96231b3b80d8
      133fae62
  23. Aug 23, 2016
  24. Aug 17, 2016
    • Chris Bieneman's avatar
      [CMake] Workflow improvements to PGO generation · eb1960e7
      Chris Bieneman authored
      This patch adds a few new convenience options used by the PGO CMake cache to setup options on bootstrap stages. The new options are:
      
      PGO_INSTRUMENT_LTO - Builds the instrumented and final builds with LTO
      PGO_BUILD_CONFIGURATION - Accepts a CMake cache script that can be used for complex configuration of the stage2-instrumented and stage2 builds.
      
      The patch also includes a fix for bootstrap dependencies so that the instrumented LTO tools don't get used when building the final stage, and it adds distribution targets to the passthrough.
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278862 91177308-0d34-0410-b5e6-96231b3b80d8
      eb1960e7
  25. Jul 27, 2016
  26. Jul 26, 2016
  27. Jul 25, 2016
  28. Jul 10, 2016
  29. Jul 09, 2016
  30. Jun 29, 2016
  31. Jun 24, 2016
    • Chris Bieneman's avatar
      [CMake] Remove CLANG_APPEND_VC_REV option · 7c599a54
      Chris Bieneman authored
      I added this option in r257827 to try and add compatibility with autoconf. At the time I misunderstood the problem.
      
      Our CMake automatically generates the SVN revision information and generates a build action to update it so builds don't need to be re-configured on SCM update (which is a better solution than we had in autoconf).
      
      The problem I was actually seeing was isolated cases where SVN revision information isn't available because the repository structures have been removed. This happens in some automated testing systems.
      
      This patch allows SVN_REVISION to be overridden if the build configuration could not find the SCM repository structures, and removes the code from my original patch because it is unnecessary.
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273714 91177308-0d34-0410-b5e6-96231b3b80d8
      7c599a54
  32. Jun 21, 2016
  33. Jun 10, 2016
  34. Jun 09, 2016
Loading