[llvm-commits] [PATCH][CMake] Removing LLVMLibDeps.cmake and exporting libraries for CMake clients.

[Douglas Gregor]

On Sep 8, 2010, at 7:34 PM, Óscar Fuentes wrote:

> [llvm-dev ml elided]
> 
> Michael Spencer <bigcheesegs at gmail.com>
> writes:
> 
>> The attached patches remove this requirement,
> 
> Your patch switches from automatic to manually maintained library
> dependencies. On the case of LLVM, that increases the workload of the
> maintainer and it is the CMake equivalent of spaghetti code. Only a
> strong benefit would justify that.

There are numerous benefits to explicitly-maintained library dependencies:
	- It's clear what those dependencies are, which leads to better understanding of the system as a whole

	- Changes in dependencies, which are fundamentally architectural changes, become obvious when they happen

	- Dependencies can make their way into other tools far more easily, e.g., component-based CPack installers  (e.g., http://www.paraview.org/Wiki/CMake:Component_Install_With_CPack)

	- It's clean and easy-to-understand, unlike our implicit dependency-generation scripts (and mapping from those to CMake dependencies)

	- On the "make" side of the world, explicit dependencies could improve build performance by exposing more parallelism. CMake-generated make files build faster than the autotools-generated makefiles, partly for this reason

>> and add real CMake
>> package export capabilities. A CMake user wishing to use LLVM can now
>> use something similar to this:
>> 
>> cmake_minimum_required(VERSION 2.8)
>> 
>> find_package(LLVM REQUIRED)
>> add_definitions(${LLVM_CXXFLAGS})
>> add_executable(llvm-external-test llvm-external-test.cpp)
>> target_link_libraries(llvm-external-test ${LLVM_SYSTEM_LIBS}
>> ${LLVM_JIT_LIBS} ${LLVM_NATIVECODEGEN_LIBS})
> 
> How is that better than
> 
> http://www.llvm.org/docs/CMake.html#embedding
> 
> ? Think that it is usual practice to have and use multiple LLVM builds
> with different configurations on the same system.

For one, find_package is the standard CMake way of finding a package, so we should be providing that to CMake users. 

CMake's export is designed to make it easy to get find_package working well, with versioning, the ability to directly depend on the exported project's targets, etc. One huge benefit to doing exporting/find_package well is that it would make it easier to separate the LLVM core from, e.g., Clang, because LLVM could export its targets and Clang could just import them via find_package. The rest of Clang's CMakeLists.txt files shouldn't have to change. That could be a big win for IDE users, because it would make it easier to create a project for just Clang that depends on a built or installed LLVM. The same CMakeListst.txt (minus the find_package, of course) would also work in-tree for those who want one giant LLVM+Clang+whatever project.

>> llvm+clang compile with these changes on both Linux and MSVS.
>> Currently both patches must be applied at the same time. I can
>> refactor them into a 3 step process if needed.
>> 
>> Does this break anything for anyone?
> 
> If that is accepted (and for now I see no reason for accepting it)
> extensive testing on all major platforms (Linux, OS/X,
> Windows/mingw/MSVC++) is required before throwing away the current
> method, wich has its limitations, but we know them.


Michael has addressed the problems that cropped up. Do we know of any other problems that need to be addressed?

	- Doug