Why does cmake use LLVMBuild.txt to specify the LLVM-libs link order?

Hi,

I've been working on a set of patches to statically link polly in the LLVM
tools. There remains an error I can't seem to solve when linking llvm-lto (all
other tools luckily get linked correctly): it insists adding libLLVMipo.a after
libLLVMPolly.a on the link command, resulting in an error of the form:

PassManagerBuilder.cpp:(.text+0x499): undefined reference to `registerPollyEarlyAsPossiblePasses

Digging a bit in the machinery of the cmake builds, I realized that the order in
which the libLLVM*.a are output depends on the contents of the LLVMBuild.txt
processed by a script: utils/llvm-build/llvmbuild/main.py that creates a
LLVMBuild.cmake file in the build dir specifying the link time dependences on a
lib: for example,

./LLVMBuild.cmake:set_property(GLOBAL PROPERTY LLVMBUILD_LIB_DEPS_LLVMipo LLVMAnalysis LLVMCore LLVMInstCombine LLVMObjCARCOpts LLVMScalarOpts LLVMSupport LLVMTarget LLVMTransformUtils LLVMVectorize LLVMipa)

The dependences set by the LLVMBuild.txt infrastructure are redundant with the
dependences specified in the CMakeLists.txt using add_dependencies as in:

add_dependencies(LLVMipo intrinsics_gen)

That also means that a conditional cmake dependence of the form:

if (WITH_POLLY AND NOT POLLY_BUILD_SHARED_LIB)
  add_dependencies(LLVMipo LLVMPolly)
endif (WITH_POLLY AND NOT POLLY_BUILD_SHARED_LIB)

is not satisfied on the link command (the only place the add_dependencies is
currently used is to establish a build order of the components.)

It seems to me that the LLVMBuild.txt machinery is pretty rigid in dealing with
optional dependences: there is no way to specify that a lib dependnece is
optional, as LLVMBuild.txt files are not "instantiated" by the configure step,
as a *.cmake or *.in file would be.

Is there a reason to not use the cmake add_dependencies to establish the link
order of the LLVM libs instead of using the LLVMBuild.txt info?

Thanks,
Sebastian

Have you tried `target_link_libraries`? The new CMake book has an
example showing one static lib depending on another (page 25):
`target_link_libraries(foo bar)` where `foo` uses symbols from `bar`.

-Greg

Greg Fitzgerald wrote: