similar to: cmake finishes OK for all the projects except debuginfo-tests.

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

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

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

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

Hello everyone, We're a little bit behind schedule, but RC1 is now here. It was tagged earlier today as llvmorg-11.0.0-rc1. Source code and docs are available at https://prereleases.llvm.org/11.0.0/#rc1 and https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc1 Pre-built binaries will be added as they become available. Please file bug reports for any issues you find as

Thanks! I'll get this posted on the web site. The "Performing Test ... failed to compile" failures from cmake are not interesting. But could you look in the log file and try to see what were the tests that failed in the "check-all" step? On Thu, Sep 12, 2019 at 4:39 PM Neil Nelson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Xubuntu/Ubuntu 19.04,

It may be that the 'not' operator is not being found under bash at : 'RUN: at line 12';   not Perhaps this is would be better as the more commonly seen '!'. Neil Nelson On 9/13/19 12:12 PM, Neil Nelson via llvm-dev wrote: > > Toward the end of testing.9.0.0-rc4.log. > > Testing: 0 .. 10.. 20. > FAIL: Clang Tools :: clang-tidy/run-clang-tidy.cpp (17057 of

Hello everyone, It took a bit longer than planned due to master being a somewhat unstable at the branch point, but Release Candidate 1 has now been tagged as llvmorg-10.0.0-rc1. Source code and docs are available at https://prereleases.llvm.org/10.0.0/#rc1 Pre-built binaries will be added there as they become available. Please file bug reports for any issues you find as blockers of

Sounds like that was fixed on trunk also, in 0e8608b (I get the same on Windows.) On Tue, Jul 7, 2020 at 8:10 AM Neil Nelson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Uploaded Ubuntu 20.04 > > sha256sum clang+llvm-10.0.1-rc3-x86_64-unknown-linux-gnu.tar.xz > 9a2b573b69a4c3d62d7a4accd9b164044cd5e8fbe68b056716c72cd0f81a134d > > FAIL: LLVM ::

Hi, I've tagged LLVM 10.0.1-rc3. This will hopefully be the last release candidate, please test it out and report results on this thread. Thanks, Tom

Every additional dependency that we force the user to manually install (either by building from source, or adding some new PPA to their ubuntu system), raises the barrier to entry that much higher. Just because we may require the user to manually install some newer compiler on their system doesn’t mean that we should also require them to install some newer CMake than what’s on their system.

Hi, I've tagged 10.0.1-final. Testers, please begin uploading your binaries. Thanks, Tom

I think it does make a difference how many things we ask new developers to do to get up and running - because we've asked them to do one thing doesn't mean it's low-cost to ask them to do another thing. On Tue, Apr 7, 2020 at 11:20 AM Mehdi AMINI via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Tue, Apr 7, 2020 at 9:16 AM Chris Tetreault <ctetreau at

Hi, I've tagged the 10.0.1-rc2 release, please test the release and report any issues. Thanks, Tom

On 14 December 2014 at 20:50, David Majnemer <david.majnemer at gmail.com> wrote: > Just a reminder, these bots are still not operational because of this > change. Well, there were valid objections to lowering the requirement. If we can require the host compiler to be upgraded, it is probably ok to require python to be upgraded too, no? Cheers, Rafael

Hi, I've tagged the 8.0.1-rc4 release, please begin testing. This will (hopefully) be the last release candidate. If all goes well, I will tag the final release next Wednesday. -Tom

Hi Manoj, I tried a few other options myself: * function 'target' attribute - the list of extensions this supports isn't complete and it doesn't enable the ACLE macros needed for intrinsics * manually defining ACLE macros - this allows intrinsics and is additive but assumes that you're not relying on codegen to emit instructions. I don't think it helps the bug linked

Hi all, In response to this issue[0] on Bugzilla, I recently committed changes to make assembly directives case insensitive for generic directives and their aliases[1], ARM[2] and AArch64[3]. (since those are the targets I have knowledge of) I realise this was probably a bit too hasty of me, so I'm writing this to gather feedback on how to proceed. Some concerns were raised that it may be