Thanks for your reply.
The “build/Debug/lib” and "build/Release/lib” directories is where all the libraries go. Similarly, the executables go to “build/Debug/bin” and “build/Release/bin” before they are moved to the install directory. This is expected and normal. However, the problem is that a small number of libraries (exactly 20 in total) are not created at all for the LLVM 9.0 version that I cloned from gitHub. These libraries are in fact not created anywhere!.
I still have LLVM 7.0 installed in my computer and the libraries for that version are all there in the right places under the LLMV 7.0 directory, but in that case I installed it all in a different way as I said, loosing the benefits of git.
I forgot to mention that “llc” alone compiles and links correctly without any issue. The problem is only when I try to get ‘clang’ compiled.
You mention that you enabled a lot of projects: "clang;clang-tools-extra;compiler-rt;debuginfo-tests;libclc;libcxx;libcxxabi;libunwind;lld;lldb;llvm;openmp;parallel-libs;polly;pstl”. I only really need the basic installation of “clang”, and I do not need any testing tools because all I want is to add my custom target to it. I also tried "clang;libclc;libcxx” but the problem with the missing libraries is exactly the same.
Just as a matter of information: I successfully implemented a custom target backend, and have it almost finished and running perfectly on LLVM 7.0. Now, I just want to move it to LLVM 9.0, but got stuck in what is supposed to be the easiest part which is just compiling it (??), but I do not understand why it doesn’t compile!
Just completed a good clang compile built from a mostly vanilla Xubuntu 19.04 VM, installed the llvm-needed Ubuntu packages, downloaded a new copy of llvm using the noted llvm install page, configured using
cmake -G Ninja -DLLVM_ENABLE_PROJECTS=“clang” -DLLVM_USE_LINKER=lld -DCMAKE_BUILD_TYPE=“Release” -DCMAKE_INSTALL_PREFIX=/home/nnelson/Documents/llvm/install …/llvm &> cmake.log
which is primarily different from yours where I am using a ‘Release’ build to avoid the much larger memory and disk usage of a ‘Debug’ build. The ‘ninja install’ command put everything in llvm/install as expected including clang. I look through cmake.log to see if there are errors that need to be corrected.
My differences appear to be Xubuntu, the packages, ninja, and the cmake line.
On Linux I can use
ninja &> ninja_compile.log
to look at the compile history and see if something went wrong.
I understand that a difference between ninja and xcode is they use a different way to determine code dependencies. So to my understanding xcode needs dependencies to be properly created whereas ninja just doesn’t care. Maybe this is why ninja is able to find what it needs for the compilation to succeed, but not xcode.
So I have now looked at the CMakeLists.txt files and found that all the missing libraries are defined in files under the ‘clang’ directory.
The llvm_project clone has the following structure:
Everything under ‘llvm’ is properly compiled with no issues, however what is under ‘clang’ fails to compile (with linker errors) even if -DLLVM_ENABLE_PROJECTS=“clang” is specified.
I suspect now that there may be some kind of bug in the llvm project that prevents this to work properly, or maybe something else needs to be done to get clang compiled on xcode. I also suspect that this may pass unnoticed when using ninja because it simply uses it’s own way to find dependencies (but I don’t really know anything about ninja).
Maybe this may help somebody to figure out what could be happening and hopefully help me to narrow the issue? I honestly am totally lost on what to try next. This is kind of ridiculous.
I also filled a bug report. I think this is actually a bug
Try using ninja generator, most people do not use Xcode for building, so since it lesser-used, it also lesser tested. Note that it’s perfectly possible to use Xcode for code browsing, debugging, editing while using ninja for building, which is what I think most people do
I understand what you say and I have been suggested this a couple of times, but I really don’t want to make the switch to ninja. I’m a retired senior software developer and I just use LLVM for a custom backend that I have already almost completed in LLVM 7.0. I’m not really into LLVM-project development, and Xcode is both familiar and fast enough for incremental builds of ‘llc’ or ‘clang’ alone including my target backend, (or it used to be in 7.0). It’s just the right tool for me.
On the other hand I think that in case there’s no intention to fully support Xcode in the future, then it should be removed from de doc descriptions to prevent deceptive information. Otherwise, at least major issues like this one, should be taken care of.
I’m not saying you can’t use Xcode, I’m just saying that instead of building in Xcode, just type “ninja” on the command line to do your build and then use Xcode as you normally would.
I don’t think it’s the case that LLVM does not intend to support Xcode, just that its a community driven project, so unless someone is sufficiently motivated to fix whatever this problem is, it might stay this way for some time. On that note, patches are certainly welcome, but if you just want to unblock yourself, the easiest way is going to be to type a command on the command line to do your build instead of pressing a button in the UI (and you could still use the UI for everything else)
Please, would you describe me step by step how do I get both a Xcode project and a Ninja setup for compiling the same?
I have downloaded the Ninja-mac binary from here https://github.com/ninja-build/ninja/releases and have setup system path to it. What’s next?
Joan, For ninja here I would do the following, noting
rm -rf build
Your cmake line might be
cmake -G Ninja -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_INSTALL_PREFIX=/Users/joan/LLVM-9/install -DLLVM_OPTIMIZED_TABLEGEN=On …/llvm
I would use
cmake -G Ninja -DLLVM_ENABLE_PROJECTS=“clang” -DLLVM_USE_LINKER=lld -DCMAKE_BUILD_TYPE=“Release” -DCMAKE_INSTALL_PREFIX=/Users/joan/LLVM-9/install …/llvm
I am not familiar with Xcode. But if the above works you might be in a position to use the executables and libraries in the just installed directory in an Xcode project.
I don’t personally develop on Mac (i use Windows), but I have an analogous setup there where i use ninja to build and Visual Studio for editing, debugging, etc.
What i do, and I assume it will be the same or very similar for Xcode, is to run cmake twice, once with Ninja, and once with VS (Xcode for you), from separate directories. I build with the ninja one (“ninja clang” on command line), and I change the debugger target from the default to point directly into my ninja directory , so VS is debugging the thing that was built with ninja.
Hopefully that makes sense
I looked into the Xcode build issue that you’re experiencing, and it relates to a limitation in Xcode which was surfaced by a CMake change I made a few months back. The issue is that Xcode can’t handle library targets that don’t have any sources associated with them, and I made a change to how we build clang so that we generate object libraries for every target then build a static library from the object target.
Long story short, I actually think I have a fix for it.
I should have a patch up for review today.
Take a look at this patch, and see if it resolves your issue:
I applied the .diff according to your changes and it worked!! Thank you very much for that.
I observed now that after building the “install” scheme, a number of new directories where created at the same level of my llvm-project clone directory.
LLVM.build benchmarks examples include install lib llvm-project tools unittests utils
The ‘install’ directory was created by me and that’s where all the executables went as per my cmake command line.
However I’m unsure if the remaining directories are supposed to be there as well, as most of them appear to contain intermediate files or files used for build purposes (I don’t really know). Please, forgive me if this is ok, the presence of these directories is not a problem as everything seems to work ok now, but I just am curious. I will update your review with my accepted revision later today.
Creating directories and files outside the build directory is not expected, and not great. I really don’t know what would cause that.