search for: alltargetsinfos

...ory to be > able to depend on the right library, have that bring in the right > dependencies, etc. > As designed, TargetSelect.h doesn't fit neatly into the normal way of arranging libraries. I'd mark it textual and leave it alone. Alternatively, we could make AllTargetsDescs and AllTargetsInfos and all the other synthetic libraries in CMake into real libaries and sink the bodies of these inline functions into each tiny little library. Doesn't seem quite worth it, though. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail...

...f-lined if/when desired, because they layering isn't fully/correctly represented in the build system. Modular codegen's been a good justification to flush out & fix several of these tricksy layering violations in LLVM already. > > Alternatively, we could make AllTargetsDescs and AllTargetsInfos and all > the other synthetic libraries in CMake into real libaries and sink the > bodies of these inline functions into each tiny little library. Doesn't > seem quite worth it, though. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://list...

As the question asks, I'm having some trouble using initializeAllTargets(). I have a CMakeLists that uses: llvm_map_components_to_libnames(LLVM_LIBS ... AllTargetsAsmParsers AllTargetsAsmPrinters AllTargetsDescs AllTargetsInfos ...) However, even with these, when I try to compile my program, I get linker errors: CMakeFiles/sxhc.dir/src/main.cpp.o: In function `llvm::InitializeAllTargets()': /home/bollu/.local/include/llvm/Config/Targets.def:27: undefined reference to `LLVMInitializeNVPTXTarget' CMakeFiles/s...

...'t fully/correctly represented in the build system. Modular codegen's >> been a good justification to flush out & fix several of these tricksy >> layering violations in LLVM already. >> >> >>> >>> Alternatively, we could make AllTargetsDescs and AllTargetsInfos and all >>> the other synthetic libraries in CMake into real libaries and sink the >>> bodies of these inline functions into each tiny little library. Doesn't >>> seem quite worth it, though. >>> >> -------------- next part -------------- An HTML attach...

...ally out-of-lined if/when desired, because they layering isn't fully/correctly represented in the build system. Modular codegen's been a good justification to flush out & fix several of these tricksy layering violations in LLVM already. Alternatively, we could make AllTargetsDescs and AllTargetsInfos and all the other synthetic libraries in CMake into real libaries and sink the bodies of these inline functions into each tiny little library. Doesn't seem quite worth it, though. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail...

So, I'm setting about trying to fix the layering of TargetSelect.h (& TargetRegistry.h, but haven't really got to its issues yet). The issues can be demonstrated fairly plainly by moving any/all of TargetSelect.h's functions out of line. Pretty much all programs in LLVM fail to link because libSupport doesn't actually depend on all the targets, quite the opposite in fact. So,