search for: llvm_external_

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

...Creating symlinks" Is it possible to configure the build without modifying the llvm.src directory (by creating those symlinks)? I see there is a '--with-clang' option. Is there a general mechanism for pointing the build to external directories similar to the one in the CMake build? LLVM_EXTERNAL_<name>_SOURCE_DIR > $BuildDir/llvm.src/configure --prefix=$InstallDir Is there a version of this script that configures the build with CMake? Thanks, Greg

...ot of the build. I'm not familiar enough with CMake to know if it's possible to just make this a couple-lines CMakeLists.txt that includes llvm/CMakeLists.txt, or if something else is needed to make this work. // Martin On Tue, 29 Oct 2019, Shoaib Meenai via llvm-dev wrote: > > LLVM_EXTERNAL_*_SOURCE_DIR can be used for specifying paths to external > clang, etc., and I agree that with the monorepo, there’s one canonical > location for those sub-projects to live, and we don’t need to support it for > those subprojects. However, LLVM_EXTERNAL_*_SOURCE_DIR can also be used in >...

Dan Liew <dan at su-root.co.uk> writes: > On 7 July 2015 at 15:05, David A. Greene <greened at obbligato.org> wrote: >> I'm learning the cmake build. >> >> Is there a way to disable the build of a subdirectory in llvm/projects? >> I'm getting a build error on one project and don't want it to hold up >> the build of everything else. >

...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-runtime sub-projects should remain. This specifically would relate to clang and lldb, and whether or not they can be built against installed or separately built copies of LLVM. There were points on both sid...

Are the packaging scripts used to produce the clang+llvm binaries on llvm.org under version control? If so, can you please point me to them? Thanks, Greg

On Tuesday 09 July 2013 15:11:03 Greg Fitzgerald wrote: > Are the packaging scripts used to produce the clang+llvm binaries on > llvm.org under version control? If so, can you please point me to > them? The script used for building the binaries can be found under llvm : utils/release/test-release.sh The packages are mere tarballs of the installation dir. Cheers, > > Thanks,

...> to documentation) for how to run compiler-rt tests? Just invoking llvm-lit > doesn't seem to work > They should run as part of check-all when you have compiler-rt checked out in llvm/projects/ (or the equivalent with the monorepo setup, which I think is just setting the appropriate LLVM_EXTERNAL_*_SOURCE_DIR cmake variable). I forget, but I'd be surprised if there isn't a "check-compiler-rt" or similar. I've also used llvm-lit in the past (look at what check-compiler-rt does; I think it just calls llvm-lit). -- Sean Silva > > On 01/03/2018 11:17 PM, Sean Silva...

...when projects were not > embedded within the llvm source tree (mostly in use by Takumi's flat > buildbots that checout the top-level project without embedding, say, clang > or compiler-rt within the llvm source tree)? > > > You are confusing this with the similarly > named LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR variables. > Ah, right - indeed. > > 2) The new way, is to place compiler-rt under LLVM/runtimes. In this path > the build system will automatically build with the just-built compiler. > This path also splits compiler-rt into two separate build steps, one tha...

Ah, that makes a lot of sense. Thank you! Do you have any tips (or points to documentation) for how to run compiler-rt tests? Just invoking llvm-lit doesn't seem to work On 01/03/2018 11:17 PM, Sean Silva wrote: > Typically this would be tested alongside the runtime component in > compiler-rt. > For example, PGO instrumentation has its "end-to-end" tests in >

Typically this would be tested alongside the runtime component in compiler-rt. For example, PGO instrumentation has its "end-to-end" tests in https://github.com/llvm-mirror/compiler-rt/tree/master/test/profile -- Sean Silva On Tue, Jan 2, 2018 at 11:16 AM, Eli Davis via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello! > > I am writing an instrumentation pass using

...be un-impacted. Distribution workflows can use the `LLVM_DISTRIBUTION_COMPONENTS` option to hand tailor which parts of LLVM to build and install with better control without as much complication. > > Many other options exist to support a wide variety of divergent workflows. For example, the `LLVM_EXTERNAL_${PROJECT}_SOURCE_DIR` options exist to allow users to specify custom paths for projects so that, historically, they didn't need to nest clang inside LLVM. With the move to the mono-repo we should define consistent workflows and eliminate options that support divergent workflows. > > ###...

On Wed, Mar 8, 2017 at 2:55 PM Chris Bieneman <beanz at apple.com> wrote: > David, > > This is an area that has had a lot of development over the last two years. > > There are two supported ways in the LLVM build system to build compiler-rt > with the just-built compiler. > > 1) The legacy way is for if compiler-rt is under LLVM/projects. You can > specify

...when projects were not > embedded within the llvm source tree (mostly in use by Takumi's flat > buildbots that checout the top-level project without embedding, say, clang > or compiler-rt within the llvm source tree)? > > > You are confusing this with the similarly > named LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR variables. > > > Ah, right - indeed. > > > 2) The new way, is to place compiler-rt under LLVM/runtimes. In this path > the build system will automatically build with the just-built compiler. > This path also splits compiler-rt into two separate build s...

...ows should be un-impacted. Distribution workflows can use the `LLVM_DISTRIBUTION_COMPONENTS` option to hand tailor which parts of LLVM to build and install with better control without as much complication. Many other options exist to support a wide variety of divergent workflows. For example, the `LLVM_EXTERNAL_${PROJECT}_SOURCE_DIR` options exist to allow users to specify custom paths for projects so that, historically, they didn't need to nest clang inside LLVM. With the move to the mono-repo we should define consistent workflows and eliminate options that support divergent workflows. ### Adopting C...

...when projects were not > embedded within the llvm source tree (mostly in use by Takumi's flat > buildbots that checout the top-level project without embedding, say, clang > or compiler-rt within the llvm source tree)? > > > You are confusing this with the similarly > named LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR variables. > > > Ah, right - indeed. > > > 2) The new way, is to place compiler-rt under LLVM/runtimes. In this path > the build system will automatically build with the just-built compiler. > This path also splits compiler-rt into two separate build s...

Hi folks, I've been working for a few months on a proposal to make it easier to develop out-of-tree passes, and have them linked either statically or dynamically, within LLVM. This includes automatic integration within clang, opt and bugpoint. The goal is to lower the bar for people who develop out-of tree passes: they can maintain their code base in a third-party repo, pick it at config

...t", "$output_file"); + exit 1; +} +else { + exit 0; +} local:/Users/dhinton/projects/llvm_project/llvm $ git diff master diff --git a/CMakeLists.txt b/CMakeLists.txt index 8cd9d053c63..7d0fe05b511 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -110,7 +110,7 @@ endif() # LLVM_EXTERNAL_${project}_SOURCE_DIR using LLVM_ALL_PROJECTS # This allows an easy 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;lib...

...; +} >> >> local:/Users/dhinton/projects/llvm_project/llvm $ git diff master >> diff --git a/CMakeLists.txt b/CMakeLists.txt >> index 8cd9d053c63..7d0fe05b511 100644 >> --- a/CMakeLists.txt >> +++ b/CMakeLists.txt >> @@ -110,7 +110,7 @@ endif() >> # LLVM_EXTERNAL_${project}_SOURCE_DIR using LLVM_ALL_PROJECTS >> # This allows an easy 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") >> +s...

...t; +else { > + exit 0; > +} > > local:/Users/dhinton/projects/llvm_project/llvm $ git diff master > diff --git a/CMakeLists.txt b/CMakeLists.txt > index 8cd9d053c63..7d0fe05b511 100644 > --- a/CMakeLists.txt > +++ b/CMakeLists.txt > @@ -110,7 +110,7 @@ endif() > # LLVM_EXTERNAL_${project}_SOURCE_DIR using LLVM_ALL_PROJECTS > # This allows an easy 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_PROJ...