similar to: RFC: A top level monorepo CMake file

On 06/18/2020 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

[Cross-post to llvm-dev to make 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

Thanks Shoaib for a great summary. To summarize this as an answer to Louis' questions: 1. What is a "Standalone build"? What does it enable that a normal monorepo build can't? This means building any of the runtimes separately, where the runtime's CMakeLists.txt (e.g. path/to/my/llvm-project/libcxx/CMakeLists.txt) is the top-level one. The reason for using this variant is

> On Jul 28, 2016, at 12:59 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 28 Jul 2016 8:36 a.m., "David Chisnall via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > This does not apply to libc++. We support building the entire LLVM suite with other C++ standard library implementations (at

> On Jul 28, 2016, at 10:53 AM, Justin Lebar <jlebar at google.com> wrote: > > Thanks again for your thoughts, Chris. > >> As a straw man I would suggest the following criteria for inclusion into the mono-repo: >> >> (1) Projects in the mono-repo must be tightly coupled to specific versions or commits of other projects in the mono-repo > > I'm fine

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

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

Today, there're two different locations for runtimes files within Clang's installation: compiler-rt: headers: $prefix/lib/clang/$version/include(/sanitizer) libraries: $prefix/lib/clang/$version/lib/$os/libclang_rt.$name-$arch.$ext libc++, libc++abi, libunwind: headers: $prefix/include/c++/v1 libraries: $prefix/lib/$name.$ext The scheme used by libc++, libc++abi, libunwind

> On Jul 28, 2016, at 12:05 PM, Justin Lebar <jlebar at google.com> wrote: > >>> The decision of whether or not to include these projects >>> affects only read-write consumers of these projects -- of which there >>> are relatively few people. >> >> Maybe there are few, but the impact is non-insignificant. Also I think the opinions of the

> On Sep 22, 2020, at 15:28, Eric Christopher <echristo at gmail.com> wrote: > > From the "not largely affected" camp: > > - the churn doesn't feel that major for HAS_ and ... > - the uniformity feels nice > > and in general feels nice and in pursuit of the longer term goals here. > > -eric > > On Tue, Sep 22, 2020 at 11:58 AM Petr

We've been using the runtimes build for a while now and we're very happy with it. However, with an increasing number of targets, it can be fairly slow and I have noticed that we now spend more time in CMake than in Ninja. There are various ways we could improve things like eliminating unnecessary checks. When running checks like check_c_compiler_flag, check_cxx_compiler_flag or

Speaking on how to locate/enable projects (like clang/lldb) - even with the monorepo, I'm still enabling clang/lldb by symlinking them into llvm/tools, for one specific reason: CMake and relative paths. As long as all the source that is being built is below the toplevel CMake directory, and the build directory itself is within the toplevel CMake project directory, CMake uses relative

On Tue, Dec 19, 2017 at 8:33 AM Jonathan Roelofs <jonathan at codesourcery.com> wrote: > On 12/19/17 9:15 AM, Petr Hosek via llvm-dev wrote: > > Today, there're two different locations for runtimes files within > > Clang's installation: > > > > compiler-rt: > > headers: $prefix/lib/clang/$version/include(/sanitizer) > > libraries: >

> On Sep 24, 2020, at 23:52, Petr Hosek <phosek at chromium.org> wrote: > > Using more interface libraries is definitely the right direction and a modern way to use CMake. I'm not sure if we can get to a single interface target since different runtimes have different requirements. I was assuming that we would have one interface target per dependency and use the existing CMake

Is this intended to be the monorepo that eventually becomes the official repo, because if so I strongly object to putting libunwind, libc++ and libc++abi in it. I have recently been working on bring-up for libc++ and libunwind on a new platform and the integration of libunwind with the LLVM build system is already annoying (you can’t build it unless you have a working C++ standard library

Hi, The minimum CMake version currently advertised for libc++ and libc++abi is currently 3.4.3. I think the oldest version of CMake actually being tested on any builder is 3.7.0, so advertising 3.4.3 is somewhat of a lie (I'm pretty sure we're using features that require a more recent version already). However, we do need to bump it to 3.8.0 at least because CMake 3.7 doesn't know

On 8 May 2017, at 20:51, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > 2017-05-07 1:01 GMT-07:00 David Chisnall via llvm-dev <llvm-dev at lists.llvm.org>: > Is this intended to be the monorepo that eventually becomes the official repo, because if so I strongly object to putting libunwind, libc++ and libc++abi in it. I have recently been working on bring-up for libc++

On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote: > In October, there was a discussion about updating CMake to 3.15: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html. No decision was made, but maybe we should revisit that proposal? If we're going to require a newer version of CMake for some subprojects, I'd prefer to bump the minimum CMake version for all of LLVM.

On Jan 13, 2017, at 1:37 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The main outcome of the BoF had the dev meeting was that we agree’d that moving to GitHub was the best choice forward for LLVM (IIRC only one person in the room expressed concerned about GitHub, but he said he had personal grief with them and nothing specific for LLVM). > > The unknown that

Thanks a lot, but tried it and I get this: CMake Error at projects/libcxx/CMakeLists.txt:361 (message): LIBCXX_ENABLE_STATIC_ABI_LIBRARY is not supported on OS X Why is it not supported? If I manually embed libc++abi.a inside libc++.a it seems to work. Thanks! ardi On Mon, Oct 1, 2018 at 4:20 AM Petr Hosek <phosek at chromium.org> wrote: > > You can use