llvm-project/clang/lib/FrontendTool/CMakeLists.txt

set(LLVM_LINK_COMPONENTS
  Option
  Support
  )

set(link_libs
  clangBasic
  clangCodeGen
  clangDriver
  clangExtractAPI
  clangFrontend
  clangRewriteFrontend
  )

if(CLANG_ENABLE_ARCMT)
  list(APPEND link_libs
    clangARCMigrate
    )
endif()

if(CLANG_ENABLE_STATIC_ANALYZER)
  list(APPEND link_libs
    clangStaticAnalyzerFrontend
    )
endif()

add_clang_library(clangFrontendTool
  ExecuteCompilerInvocation.cpp

  DEPENDS
  ClangDriverOptions

  LINK_LIBS
  ${link_libs}
  )
[CMake] clang/lib: Satisfy dependencies to add actually used libraries on target_link_libraries() and LLVM_LINK_COMPONENTS. I will prune redundant dependencies later. llvm-svn: 196800 2013-12-09 19:04:43 +00:00			`set(LLVM_LINK_COMPONENTS`
			`Option`
			`Support`
			`)`

[CMake] Use LINK_LIBS instead of target_link_libraries(). llvm-svn: 202238 2014-02-26 06:41:29 +00:00			`set(link_libs`
[CMake] clang/lib: Satisfy dependencies to add actually used libraries on target_link_libraries() and LLVM_LINK_COMPONENTS. I will prune redundant dependencies later. llvm-svn: 196800 2013-12-09 19:04:43 +00:00			`clangBasic`
			`clangCodeGen`
Remove a goofy CMake hack and use the standard CMake facilities to express library-level dependencies within Clang. This is no more verbose really, and plays nicer with the rest of the CMake facilities. It should also have no change in functionality. llvm-svn: 158888 2012-06-21 01:30:21 +00:00			`clangDriver`
[clang][extract-api] Refactor ExtractAPI and improve docs - The name SymbolGraph is inappropriate and confusing for the new library for clang-extract-api. Refactor and rename things to make it clear that ExtractAPI is the core functionality and SymbolGraph is one serializer for the API information. - Add documentation comments to ExtractAPI classes and methods to improve readability and clearness of the ExtractAPI work. Differential Revision: https://reviews.llvm.org/D122160 2022-03-21 00:53:28 -07:00			`clangExtractAPI`
Remove a goofy CMake hack and use the standard CMake facilities to express library-level dependencies within Clang. This is no more verbose really, and plays nicer with the rest of the CMake facilities. It should also have no change in functionality. llvm-svn: 158888 2012-06-21 01:30:21 +00:00			`clangFrontend`
Split library clangRewrite into clangRewriteCore and clangRewriteFrontend. This is similar to how we divide up the StaticAnalyzer libraries to separate core functionality to what is clearly associated with Frontend actions. llvm-svn: 163050 2012-09-01 05:09:24 +00:00			`clangRewriteFrontend`
Remove a goofy CMake hack and use the standard CMake facilities to express library-level dependencies within Clang. This is no more verbose really, and plays nicer with the rest of the CMake facilities. It should also have no change in functionality. llvm-svn: 158888 2012-06-21 01:30:21 +00:00			`)`
With CLANG_ENABLE_STATIC_ANALYZER=0, link clang properly and skip clang-check. Previously, the CMake build still tried to link clang against the static analyzer libraries, even if CLANG_ENABLE_STATIC_ANALYZER was off. Furthermore, clang-check depends on the analyzer, so it should be disabled (in both CMake and configure builds). In theory, clang-check could be made to conditionally include analyzer support (like clang itself), but for now this at least gets a CMake ALL_BUILD working. Patch by Stephen Kelly, modified by me. llvm-svn: 185548 2013-07-03 16:20:29 +00:00
Fix dependencies now that the ARC migrator depends on the static analyzer. Thanks for pointing this out, Stephen. I think this is right now -- I attempted to try all four valid combinations with both the autoconf and CMake builds. See also LLVM changes to the configure script. llvm-svn: 189027 2013-08-22 15:50:02 +00:00			`if(CLANG_ENABLE_ARCMT)`
[CMake] Use LINK_LIBS instead of target_link_libraries(). llvm-svn: 202238 2014-02-26 06:41:29 +00:00			`list(APPEND link_libs`
Fix dependencies now that the ARC migrator depends on the static analyzer. Thanks for pointing this out, Stephen. I think this is right now -- I attempted to try all four valid combinations with both the autoconf and CMake builds. See also LLVM changes to the configure script. llvm-svn: 189027 2013-08-22 15:50:02 +00:00			`clangARCMigrate`
			`)`
			`endif()`

With CLANG_ENABLE_STATIC_ANALYZER=0, link clang properly and skip clang-check. Previously, the CMake build still tried to link clang against the static analyzer libraries, even if CLANG_ENABLE_STATIC_ANALYZER was off. Furthermore, clang-check depends on the analyzer, so it should be disabled (in both CMake and configure builds). In theory, clang-check could be made to conditionally include analyzer support (like clang itself), but for now this at least gets a CMake ALL_BUILD working. Patch by Stephen Kelly, modified by me. llvm-svn: 185548 2013-07-03 16:20:29 +00:00			`if(CLANG_ENABLE_STATIC_ANALYZER)`
[CMake] Use LINK_LIBS instead of target_link_libraries(). llvm-svn: 202238 2014-02-26 06:41:29 +00:00			`list(APPEND link_libs`
With CLANG_ENABLE_STATIC_ANALYZER=0, link clang properly and skip clang-check. Previously, the CMake build still tried to link clang against the static analyzer libraries, even if CLANG_ENABLE_STATIC_ANALYZER was off. Furthermore, clang-check depends on the analyzer, so it should be disabled (in both CMake and configure builds). In theory, clang-check could be made to conditionally include analyzer support (like clang itself), but for now this at least gets a CMake ALL_BUILD working. Patch by Stephen Kelly, modified by me. llvm-svn: 185548 2013-07-03 16:20:29 +00:00			`clangStaticAnalyzerFrontend`
			`)`
			`endif()`
[CMake] Use LINK_LIBS instead of target_link_libraries(). llvm-svn: 202238 2014-02-26 06:41:29 +00:00
			`add_clang_library(clangFrontendTool`
			`ExecuteCompilerInvocation.cpp`

			`DEPENDS`
			`ClangDriverOptions`

			`LINK_LIBS`
			`${link_libs}`
			`)`