search for: llvm_enable_project

Hi, In our CMake build system there are currently two ways of specifying which LLVM sub projects to build by setting CMake cache variables. * Setting `LLVM_ENABLE_PROJECTS` to the list of projects to enable (e.g. `-DLLVM_ENABLE_PROJECTS=clang;compiler-rt`) * Setting `LLVM_TOOL_<PROJECT>_BUILD` boolean CMake cache variables (e.g. `-DLLVM_TOOL_CLANG_BUILD=ON -DLLVM_TOOL_COMPILER_RT_BUILD=ON`) Having two different ways of specifying the same thing is problematic...

Folks, I'm at a loss trying to add Compiler-RT to an LLVM build, even after checking out the instructions at http://compiler-rt.llvm.org, so I'd appreciate your help. I've tried adding the CMake options LLVM_ENABLE_PROJECTS, LLVM_BUILD_EXTERNAL_COMPILER_RT, LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR, CLANG_DEFAULT_RTLIB. All to no avail. FWIW, I'm building for the targets AArch64, ARM and X86. Feeling like a newbie makes me want to cry... :-} Thank you, -- Evandro Menezes

...e sure everybody relevant sees this] Hi, I'm currently trying to simplify the libc++/libc++abi/libunwind build systems and testing setup. In doing so, I am encountering issues related to "unusual" ways of building them. By unusual, I just mean "not the usual monorepo build with LLVM_ENABLE_PROJECTS". I would like to pin down what the set of supported use cases for building the runtime libraries are. In particular, the world I would like to live in is one where the only way to build libc++/libc++abi/libunwind is: $ mkdir build $ cd build $ cmake <monorepo-root>/llvm -D...

...E_* variables and replace them with generator expressions which is a much better solution. On Wed, Apr 8, 2020 at 1:21 PM Shoaib Meenai <smeenai at fb.com> wrote: > (CCing Chris and Petr, who’ve done the most work on the runtimes build) > > > > At least for me on Linux, using LLVM_ENABLE_PROJECTS is actually the > unusual way of building libc++; I use LLVM_ENABLE_RUNTIMES. The reason is, > my host compiler is often gcc, but I want to build, test, and ship libc++ > with the clang I just built. > > > > The runtimes build is when you use LLVM_ENABLE_RUNTIMES. It sets up t...

...s via llvm-dev wrote: >> Folks, >> >> I'm at a loss trying to add Compiler-RT to an LLVM build, even after >> checking out the instructions at http://compiler-rt.llvm.org, so I'd >> appreciate your help. >> >> I've tried adding the CMake options LLVM_ENABLE_PROJECTS, >> LLVM_BUILD_EXTERNAL_COMPILER_RT, LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR, >> CLANG_DEFAULT_RTLIB. All to no avail. > > You'll need to give a lot more details on what you tried, and how it > failed. Without that information, nobody can really help you. OK, what else can...

Hi folks, Building any LLVM project currently requires invoking CMake inside <monorepo-root>/llvm, while setting the projects to enable in the LLVM_ENABLE_PROJECTS variable. This has the downside that CMake processing for the LLVM subproject happens even when one doesn't really need or want it. It's also not great from a build hygiene perspective, as LLVM globally sets some flags and subprojects pick them up, when they don't really mean to. For e...

Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> writes: > The first layout is older, and the second is newer. Going forward, > things are likely to move around. The second layout is more flexible > because it doesn't put any repo inside another repo, so I would > recommend adopting it. At the very least, using it will put you in a > good position to adapt to any

...es, and we'll need that to build libc++ properly going forward. This will mean for bot owners: 1. They need to upgrade CMake on the builders to at least 3.8.0 (which is really easy), or 2. they can disable processing of libc++ and libc++abi's CMake files by making sure they do not appear in LLVM_ENABLE_PROJECTS Any objections? Cheers, Louis

...20 11:27 AM, Steven Wu via llvm-dev wrote: > I like the proposal but I would like to go even further. If we are going to create a top level CMake file, we should just go ahead and eliminate all the standalone build configuration. The standalone build should just be `cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=standalone-project ...`. That means less build configuration to maintain which is always good. > Eliminating stand-alone builds would be an inconvenience for us in Fedora, since this is how we build LLVM packages. However, I think we may have different definitions of what a stand-alone build...

It builds fine but I cannot execute the resulting binary which aborts with the mentioned error.However I don't use LLVM_ENABLE_PROJECTS, I don't know if that changes the way libLLVM-4.0svn.so is linked... Cheers,Jonas Am Freitag, den 06.01.2017, 13:44 +0900 schrieb Rui Ueyama: > Hi Hahnfeld, > I just compiled with LLVM_LINK_LLVM_DYLIB enabled [1] and build lld with `ninja lld`. It built fine. What am I missing? > &gt...

...gt; this, I'll investigate it. > > On Fri, Jan 6, 2017 at 2:51 PM, Hahnfeld, Jonas > <Hahnfeld at itc.rwth-aachen.de> wrote: >> >> It builds fine but I cannot execute the resulting binary which aborts with >> the mentioned error. >> However I don't use LLVM_ENABLE_PROJECTS, I don't know if that changes the >> way libLLVM-4.0svn.so is linked... >> >> Cheers, >> Jonas >> >> Am Freitag, den 06.01.2017, 13:44 +0900 schrieb Rui Ueyama: >> >> Hi Hahnfeld, >> >> I just compiled with LLVM_LINK_LLVM_DYLIB enable...

Judging by this path: needed by 'tools/lld/Common/VCSVersion.inc' It looks to me like this is **not** a monorepo layout (if it were, lld would not appear in the tools directory). Therefore the LLVM_ENABLE_PROJECTS=lld is not even doing anything. I don't know how to build without a monorepo these days, and I also don't know what the most recent guidance setting up a monorepo is, but maybe someone else can chime in. On Tue, Mar 19, 2019 at 3:49 PM Shoaib Meenai via llvm-dev < llvm-dev at lists.ll...

...need that to build libc++ properly going forward. This will mean for bot owners: > 1. They need to upgrade CMake on the builders to at least 3.8.0 (which is really easy), or > 2. they can disable processing of libc++ and libc++abi's CMake files by making sure they do not appear in LLVM_ENABLE_PROJECTS > > Any objections? > > Cheers, > Louis > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/li...

cmake -G Ninja -DLLVM_ENABLE_PROJECTS="debuginfo-tests" -DLLVM_USE_LINKER=lld -DCMAKE_BUILD_TYPE="Release" -DLLVM_TARGETS_TO_BUILD=X86 -Wno-dev ../llvm &> ../../cmake.log in cmake.log -- Targeting X86 CMake Error at /home/nnelson/Documents/llvm-project/debuginfo-tests/CMakeLists.txt:30 (message):   Can...

...uild libc++ properly going forward. This will mean for bot owners: >>> 1. They need to upgrade CMake on the builders to at least 3.8.0 (which is really easy), or >>> 2. they can disable processing of libc++ and libc++abi's CMake files by making sure they do not appear in LLVM_ENABLE_PROJECTS >>> >>> Any objections? >>> >>> Cheers, >>> Louis >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists....

..., I'm trying to create a pure LLVM toolchain (that will not depend on GNU and produce GNU-free code too) on a musl based distribution. For now, I use gcc to bootstrap and build all LLVM components. I do it individually because I was running out of space and memory trying to build all using LLVM_ENABLE_PROJECTS. Also, I don't want to create a all-in-one package. Then, once I'm able to build program with clang, I'll rebuild all using clang instead of gcc. # LLVM I've built LLVM using the following configuration: -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=On -DCMAKE_...

Hi all, I recently gave LLD a try and it definitely works fine. However one cannot build it together with LLVM_LINK_LLVM_DYLIB: ELF/Driver.cpp and ELF/DriverUtils.cpp pull in llvm/Support/CommandLine.h which defines the command line options so these global variables end up in libLLVM-4.0svn.so via liblldELF. If this shared library is then linked into bin/lld or bin/opt one gets errors because of

I tried deleting my build directory and restarting from scratch $ cd llvm-project $ mkdir build && cd build $ cmake -G "Unix Makefiles" -DLLVM_ENABLE_PROJECTS=lld ../llvm $ make I got this error: make[2]: *** No rule to make target 'llvm/cmake/modules/GenerateVersionFromVCS.cmake', needed by 'tools/lld/Common/VCSVersion.inc'. Stop. CMakeFiles/Makefile2:57166: recipe for target 'tools/lld/Common/CMakeFiles/lldCommon.dir/all' fa...

cmake ../llvm/ -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Debug" -DCMAKE_INSTALL_PREFIX=../install -DLLVM_TARGETS_TO_BUILD="XXX" -DLLVM_ENABLE_PROJECTS='lld;clang;' ________________________________ From: Hans Wennborg <hans at chromium.org> Sent: Thursday, March 21, 2019 2:21 AM To: Josh Sharp Cc: Brian Cain; via llvm-dev Subject: Re: [llvm-dev] LLVM 8.0.0 Release Clang should be in the same folder. Can you share the full commands...

...way of setting up a build directory for llvm and another # one for llvm+clang+... using the same sources. -set(LLVM_ALL_PROJECTS "clang;libcxx;libcxxabi;lldb;compiler-rt;lld;polly") +set(LLVM_ALL_PROJECTS "clang;libcxx;libcxxabi;lldb;compiler-rt;lld;polly,debuginfo-tests") set(LLVM_ENABLE_PROJECTS "" CACHE STRING "Semicolon-separated list of projects to build (${LLVM_ALL_PROJECTS}), or \"all\".") if( LLVM_ENABLE_PROJECTS STREQUAL "all" ) @@ -885,13 +885,16 @@ if( LLVM_INCLUDE_EXAMPLES ) endif() if( LLVM_INCLUDE_TESTS ) - if(EXISTS ${LLVM_MAIN_S...