similar to: Some xcode schemes not appearing now in Xcode after cmake install (??)

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

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 On Sun, Jul 7, 2019 at 4:20 AM Joan Lluch via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I also filled a bug

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

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

Hey Joan, Take a look at this patch, and see if it resolves your issue: https://reviews.llvm.org/D64300 <https://reviews.llvm.org/D64300> Thanks, -Chris > On Jul 7, 2019, at 3:54 PM, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hey Joan, > > I looked into the Xcode build issue that you're experiencing, and it relates to a limitation in

Hi Nelson, 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

Hi Praveen, Thanks for the tip, but Xcode seems to spend all the time running tablegen "custom shell scripts", one by one at a time, not linking. Linking is actually very fast, possibly less than a second. The “scripts” that take longer are “AArch64CommonTableGen" and “AMDGPUCommonTableGen”. As said this is on LLVM 9.0. However, on LLVM 7.0.1, the same process takes just 5-6

Much of this has been discussed (over many, many years) on https://bugs.llvm.org/show_bug.cgi?id=28222 Some of the issues that were identified included: 1 - Poor tablegen dependency handling leading to unexpected rebuilds. 2 - Debug STL iterator checks taking an insane amount of time (might be MSVC specific). 3 - Lack of parallelization of custom commands (XCode and VS builds) - VS at least

If someone can manage it, it wouldn't be a bad thing - obviously open up more parallelism (I don't know how much of LLVM can be built before you hit everything that needs tblgen run - I guess libSupport and some other bits) On Mon, Jul 1, 2019 at 12:54 PM Zakharin, Vyacheslav P via llvm-dev < llvm-dev at lists.llvm.org> wrote: > [resending to the whole list] > > > >

Hi Praveen, Please, can you elaborate on this?. What do do mean by “building as shared objects”. Thanks, John > On 30 Jun 2019, at 07:32, Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > Maybe try building llvm as a shared objects.. > > On Jun 30, 2019 1:30 AM, "Joan Lluch via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at

Hey Joan, When looking for build support it is really useful to include a bunch of information about your build up front. Knowing that you are on macOS, and using the Xcode generator are really useful. On macOS, BUILD_SHARED_LIBS won’t really help much because the default linker (ld64) is pretty good. Using an IDE generator and setting LLVM_USE_OPTIMIZED_TABLEGEN will kill your release builds.

This is also the case with the Visual Studio generators. Custom commands in a single cmake file essentially get written out line by line into a single batch file that gets processed as a custom build step. In the VS case this means that it can, for example, run X86 and Aarch64 tablegen steps in parallel with each other but all of the individual X86 invocations get processed serially. I can well

Hi Florian, Ok, I ran this: cmake -S LLVM -DCMAKE_INSTALL_PREFIX=INSTALL -DLLVM_OPTIMIZED_TABLEGEN=On -G Xcode Compiled it again from clean, and the situation is worse than before. Incremental builds take an incredible amount of time stuck in running Tablegen scripts for all targets. Now this happens both in Release and Debug configurations. Just before this, at least Release compiled fine, but

FWIW, tablegen does not update timestamps for .inc files, if their contents is unchanged, so if you somehow affect a .td file's timestamp (without changing its contents) it will trigger rebuild of the corresponding .inc file with all subsequent incremental make builds. At the same time, this will not trigger rebuilding any targets dependent on this .inc file, since it is not modified. From

Hi Joan, On Fri, 14 Jun 2019 at 11:45, Joan Lluch <joan.lluch at icloud.com> wrote: > When I started with this, I just downloaded the sources for the LLVM site, I did not even created a git for it. Then ran the CMAKE app (not from the command line) with the default settings other than also adding the ‘experimental’ targets, and boom a fully functional XCode project was created, so I gave

Dear all, I’m developing Clang&LLVM on MacOS Catalina 10.15. Now every time I "make clang", the building systems rebuilds all the .inc files generated by cmake, which essentially rebuilds all the tablegen files in llvm, although I did not change any of the tablegen files. The building is unnecessary and slow, especially when it builds the X86GenSubtargetInfo.inc. Is there a way to

To be honest, I don’t either know what really happens under the hood when CMake creates the xCode project for CLang+LLVM. But there’s something really explicit going on there, because the project as it’s shown in xCode does not have the same file grouping structure than the actual physical folders. Not only the project file grouping doesn't match the physical folder locations, but the group

Hi all, On LLVM version 7.0.1, incremental builds are very fast for both Release and Debug. I’m compiling with Xcode I recently downloaded LLVM 9.0 from the LLVM-mirror Github repository and found that Incremental "Debug” builds take a ridiculously long time due to Tablegen taking ages (literally more than 10 minutes) to generate files. This makes it totally unusable for debug purposes.

Hi Tim I created an Xcode project with CMAKE, which should have the entire lot of files. Selecting the ‘install’ scheme Xcode compiles everything including all available targets for clang and llc, which then I can fully debug. So the Xcode project definitely has all the cpp files in it. However, I now have found that for some reason the .h files in the lib/Basic/Targets directory were not

Please, can anybody show me the required steps for running the LLVM regression tests, or point me to a detailed doc? I read the available documentation in https://llvm.org/docs/TestingGuide.html <https://llvm.org/docs/TestingGuide.html> but that's mostly a general description on what’s available rather than an “guide”. This is what I tried: - Installed both LLVM and CLANG using