llvm dev - Oct 2013 - [LLVMdev] 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
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

On Thu, Oct 31, 2013 at 12:17 PM, Sebastian Pop <spop at codeaurora.org>
wrote:
> 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?
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:
> On Thu, Oct 31, 2013 at 12:17 PM, Sebastian Pop <spop at
codeaurora.org> wrote:
> > 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?
> 
> 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`.
Thanks Greg!
Adding extra dependences in cmake with target_link_libraries works
and simplifies a bit the patches I have submitted.

I'm still wondering why cmake uses LLVMBuild.txt at all...

Sebastian
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation