search for: llvm_tool_

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 because from the CMake perspective because we can't detect which way the user actually wants to use. S...

...; the libc++ and sanitiser runtimes if you wanted to? > > > > Is it that easy to build a subset of a large checked-out tree? I haven't > > tried it but my impression is: not so much. > > It's possible to disable subsets of an LLVM build by setting the various 'LLVM_TOOL_*_BUILD' options to 'OFF' in cmake. For example, 'LLVM_TOOL_COMPILER_RT_BUILD=OFF' will prevent the build for projects/compiler-rt, and 'LLVM_TOOL_CLANG_TOOLS_EXTRA_BUILD=OFF' will disable the tools/projects/clang/tools/extra (I've just double checked the latter). IIR...

On Sat, Jul 30, 2016 at 2:26 AM, Robinson, Paul via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > Even then, are we seriously ignoring the fact that even if you did clone > > the whole repository including everything, that you can still build just > > the libc++ and sanitiser runtimes if you wanted to? > > Is it that easy to build a subset of a large

...stem functionality that could be simplified or removed, and on some points there was agreement, and on others there is need for more discussion. A few examples: There was general agreement on the concept from my RFC that the `all` target should always really be `all`. That would mean removing the `LLVM_TOOL_*_BUILD` options. There was also agreement that in the monorepo it no longer makes sense to have an option to specify the source locations of sub-projects. That means we can remove the `LLVM_EXTERNAL_*_SOURCE_DIR` variables. There was disagreement over whether or not standalone builds of non-runti...

...> or removed, and on some points there was agreement, and on others there is > need for more discussion. A few examples: > >   > > There was general agreement on the concept from my RFC that the `all` target > should always really be `all`. That would mean removing the > `LLVM_TOOL_*_BUILD` options. > >   > > There was also agreement that in the monorepo it no longer makes sense to > have an option to specify the source locations of sub-projects. That means > we can remove the `LLVM_EXTERNAL_*_SOURCE_DIR` variables. > >   > > There was disagre...

> On Oct 24, 2019, at 02:17, Alex Denisov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Chris, > > This is a great initiative and it feels like the right direction. > > I'd like to add another point to the list: using LLVM as a library, i.e. being able to add it as a CMake subproject. > Currently it works pretty good, but some parts can be improved

Hi Duncan, > […] > 2. Those working on projects *outside* the monolithic repo will get the downsides of both: a monolithic repo that they are only using parts of, and multiple repos that are somehow version-locked. > > 3. For many (most?) developers, changing to a monolithic git repo is a *bigger* workflow change than switching to separate git repos. Many people (and at least some