Displaying 5 results from an estimated 5 matches for "llvm_external_projects".
2018 May 23
1
Repo directory layout
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
2019 Feb 05
3
[RFC] [CMake] Removing support for LLVM_TOOL_<PROJECT> CMake cache variables
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
2019 Oct 29
2
RFC: LLVM Build System Future Direction
...e 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
> conjunction with LLVM_EXTERNAL_PROJECTS to specify the paths to other
> projects you want to include in your build but don’t necessarily want to
> place beside the llvm directory, e.g. Swift. We’ll continue supporting it
> for the latter use case, correct?
>
>
>
> From: llvm-dev <llvm-dev-bounces at lists.llvm...
2019 Oct 29
11
RFC: LLVM Build System Future Direction
Sorry for the delay in writing this up and sending it out, but I wanted to recap the discussion from the roundtable on October 23rd. The roundtable ran for almost two hours and we discussed at most of the main points in my RFC. Thank you everyone who participated and contributed to the discussion!
TL;DR: We should move to CMake 3.15 (RFC incoming). We should make `all` really `all`. We should
2020 Jun 20
17
[RFC] Introduce an LLVM "Incubator" Process
Hi all,
Today, we maintain a high bar for getting a new subproject into LLVM: first a subproject has to be built far enough along to “prove its worth” to be part of the LLVM monorepo (e.g. demonstrate community, etc). Once conceptually approved, it needs to follow all of the policies and practices expected by an LLVM subproject.
This is problematic for a couple reasons: it implicitly means that