Hello, Brad. Brad King <[EMAIL PROTECTED]> writes:
> Óscar Fuentes wrote: >> The script examines library interdependencies dumping the symbol >> definitions and references they contain. For this, you need to build the >> libraries first. Later on the build, the executables just provide names >> of components, the script maps this names to actual libraries and >> returns the full list of needed libraries on the correct order for using >> it on the link command. >> >> If you know an elegant way to handle this with CMake, I'll like to hear >> it. >> >> BTW, this is for the Low Level Virtual Machine (LLVM) www.llvm.org > > I assume you're refering to this script: > > http://llvm.org/svn/llvm-project/llvm/trunk/utils/GenLibDeps.pl This analyzes the dependencies. This is appended to llvm-config: http://llvm.org/svn/llvm-project/llvm/trunk/tools/llvm-config/llvm-config.in.in This script is executed within the link command (with shell backquotes) to obtain the libraries for certain set of components: $ llvm-config -libs jit native interpreter $ ./bin/llvm-config --libs jit native interpreter /d/dev/lib/llvm-git/mingw/lib/LLVMInterpreter.o /d/dev/lib/llvm-git/mingw/lib/LLVMX86.o -lLLVMLinker -lLLVMArchive /d/dev/lib/llvm-git/mingw/lib/LLVMJIT.o -lLLVMExecutionEngine -lLLVMipo -lLLVMSelectionDAG -lLLVMCodeGen -lLLVMScalarOpts -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMBitReader -lLLVMVMCore -lLLVMSupport -lLLVMSystem > It seems to rely on certain output from "nm". Does this work with any > windows compilers? No. Windows linkers (like MSVC's) are much simpler to handle. They are not sensitive to library specification order on the command line. Neither there is a need for partial linking. At least until shared libraries are supported on MSVC, just passing all libraries on the command line is enough. > Inferring dependencies among already-built static > libraries is not a design goal for CMake as it tries not to depend on > any low-level details of native tools. However, given an explicit > list of static libs and their *direct* dependencies, CMake will chain > them automatically and handle the circular cases. It seems there are Unix linkers that can't handle circular cases. This is why some libraries are partially linked as object files. > I think in the long run LLVM should just explicitly declare its > dependencies. They can't be *that* complicated. LLVM is made of components. At configure time, you choose the components you want. This affects what libraries are built and how they depends one on another. It affects the libraries every executable depend on, too. The job of `llmv-config' is hiding all this complexity when you need to link an executable with the LLVM libraries. > See below for output I got from building llvm. Would it really be so > bad to list that by hand? It's 18 lines that could be distributed > throughout each library's build files. The executables already list > their direct dependencies explicitly. I'm afraid that listing library dependencies by hand would be seen as a unaceptable regression wrt the current build system. However, I'm thinking on a two-phase build, something like this: $ cmake -G "Unix Makefiles" # as llvm-config is not available, the executables are ignored. $ make # this builds the libs and llvm-config and stops. $ make # This implicitly invokes cmake, which now can use llvm-config for determining dependencies and build the executables. It would be a good thing if the second `make' were not necessary. Thanks for looking into this, Brad. -- Oscar _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake