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

[Sebastian Pop]

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
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation