similar to: [LLVMdev] cmake updates

> I've attached a patch to fix these. This allows me to build LLVM on cygwin. Sorry, I didn't mean to include this hunk: Index: CMakeLists.txt =================================================================== --- CMakeLists.txt (revision 58429) +++ CMakeLists.txt (working copy) @@ -31,8 +31,13 @@ ) if(WIN32) - set(LLVM_ON_WIN32 1) - set(LLVM_ON_UNIX 0) + if(CYGWIN) +

Cygwin's <stdint.h> defines uint32_t as "unsigned long". I think this is valid, but it causes various problems like this when building LLVM with GCC 3.4.4: .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:3440: error: call of overloaded `AddInteger(uint32_t)' is ambiguous .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1429: error: no matching function for call to `max(long

Jay Foad <jay.foad at gmail.com> writes: >> Committed a change for the cmake build that implements the option >> LLVM_ENABLE_ASSERTS. Defaults to ON if and only if CMAKE_BUILD_TYPE is >> Release. > > Thanks! I think it might be nice to make this a bit more consistent > with Makefile.config. I'd suggest... > > - use LLVM_DISABLE_ASSERTIONS instead of

Another observation: GettingStarted.html still gives these instructions for cross-compiling LLVM: 1. Configure and build LLVM as a native compiler. You will need just TableGen from that build. * If you have $LLVM_OBJ_ROOT=$LLVM_SRC_ROOT just execute make -C utils/TableGen after configuring. * Otherwise you will need to monitor building process and terminate it just after

How about tweaking the compiler-rt cmakefiles so that if lsan is not supported, the target check-lsan still exists but does nothing? I've attached a patch that does this. (I don't know much about cmake so there might be a better way of doing it.) Alternatively, can I change the zorg build script so that "run sanitizer tests in gcc build" doesn't try to run check-lsan etc

Jay, Hiroshi, did [0] resolve the problem you've seen. [0] https://github.com/llvm/llvm-project/commit/d23c61490c282a7a8f29aaa5c021cbfdaf87fb6f On 12/10, Doerfert, Johannes wrote: > I think the problem is that only clang has a dependence on the new > library and when you check LLVM without building clang it does not exist > yet. I will commit a LLVM patch today that will cause LLVM

I'm trying to cross-compile LLVM with build=, host=target=. I'm using the following packages from Debian lenny: mingw32 4.2.1.dfsg-1 mingw32-binutils 2.18.50-20080109-1 mingw32-runtime 3.13-1 The first problem I hit was when I configured with CC, CXX, AR and RANLIB set to mingw cross-tools, but forgot to specify NM as well. This resulted in a load of warnings that scrolled off the

Hi, > Committed a change for the cmake build that implements the option > LLVM_ENABLE_ASSERTS. Defaults to ON if and only if CMAKE_BUILD_TYPE is > Release. Thanks! I think it might be nice to make this a bit more consistent with Makefile.config. I'd suggest... - use LLVM_DISABLE_ASSERTIONS instead of LLVM_ENABLE_ASSERTS - have it default to OFF (so assertions are enabled) always -

>> Thanks! I think it might be nice to make this a bit more consistent >> with Makefile.config. I'd suggest... >> >> - use LLVM_DISABLE_ASSERTIONS instead of LLVM_ENABLE_ASSERTS > > Okay. I meant ...DISABLE... instead of ...ENABLE...! >> I don't think -UNDEBUG has any effect, because NDEBUG won't have been >> defined in the first place >

This seems to be happening to me, too. I think this happens for me on "ninja check-llvm" in a clean build. Let me know if you need more info. On Tue, Dec 10, 2019 at 2:22 PM Doerfert, Johannes via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Jay, > > I am not sure why this happens. > Can you give me some information so I can reproduce it: > Is this happens

Hi Óscar, Thank you for the reply. I indeed got an impression (may be incorrect) that projects/ directory is intended for users' projects that are not committed to LLVM repository. Otherwise, of course, the patch doesn't make much sense. Anyway, I've added a comment about the need of explicit CMake invocation to projects/CMakeLists.txt. Thanks, Victor -----Original Message-----

"Viktar Zviarovich" <Viktar.Zviarovich at brunel.ac.uk> writes: > The suggested patch enables addition of all subdirectories of > llvm/projects to CMake build. > > It somewhat simplifies the process of creating new projects that use > CMake instead of make, eliminating the need of editing > llvm/CMakeLists.txt and llvm/projects/CMakeLists.txt. This is not

Johannes, This patch seems to be causing test failures when I just do "ninja check", without running "ninja" or "ninja all" first. $ CC=clang CXX=clang++ cmake -G Ninja ~/git/llvm-project/llvm -DLLVM_USE_LINKER=lld -DLLVM_PARALLEL_LINK_JOBS=4 -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 && ninja check [...] FAIL: LLVM ::

Frits van Bommel <fvbommel at wxs.nl> writes: > Paul Melis wrote: >> Just checked: yup, there's plenty of assert()'s in the headers, so >> -D_DEBUG will keep those alive. >> >> Interestingly, when configuring with --enable-optimized and >> --disable-assertions the resulting compilation calls itself a >> "Release-Asserts build" while

Hi, Oscar > at all, it would be great if you reflect your changes on the file list > inside the corresponding CMakeLists.txt when you add, remove or rename a > .cpp file. Isn't is possible for cmake just to glob everything in the corresponding directory? -- WBR, Anton Korobeynikov

Sorry, attached the wrong patch last time. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Viktar Zviarovich Sent: 04 March 2009 14:19 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] automatic discovery of new CMake projects Hi all, The suggested patch enables addition of all subdirectories of llvm/projects to

Hi all, The suggested patch enables addition of all subdirectories of llvm/projects to CMake build. It somewhat simplifies the process of creating new projects that use CMake instead of make, eliminating the need of editing llvm/CMakeLists.txt and llvm/projects/CMakeLists.txt. Best regards, Victor -------------- next part -------------- An HTML attachment was scrubbed... URL:

Óscar Fuentes wrote: > Kenneth Boyd <zaimoni at zaimoni.com> writes: > > >>>> Isn't is possible for cmake just to glob everything in the corresponding >>>> directory? >>>> >>>> >>> Yes, but then the build would not notice a change on the file >>> structure. You'll need to explicitly invoke

Hi, Currently the first stage ("run sanitizer tests in gcc build") of the sanitizer-ppc64-linux1 buildbot is only failing because of: + cd clang_build + make -j16 check-lsan make: *** No rule to make target `check-lsan'. Stop. + echo @@@STEP_FAILURE@@@ @@@STEP_FAILURE@@@ + cd clang_build + make -j16 check-msan make: *** No rule to make target `check-msan'. Stop. + echo

Hi, After reading Michael Spencer's presentation on lld (http://llvm.org/devmtg/2012-04-12/Slides/Michael_Spencer.pdf), I thought I'd try building it myself. I created projects/lld as a symlink to the lld source tree (is this the right approach?), but I had some trouble getting the llvm build system to actually build it. - a "configure"-based build only seems to know about