similar to: [monorepo] Pre-push hook to prevent pushing merge commits

On 30 Jun 2020, at 16:04, Louis Dionne via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> On Apr 8, 2020, at 13:06, Louis Dionne <ldionne at apple.com> wrote: >>> On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Okay, so we've had some discussion on this thread, and although some people

It is curious to me that we had so much push back about moving host-compiler versions, yet so little on the cmake versions. In my opinion, we need to have a unified ‘dependency age’ policy. Cmake 3.13.4 was released about 18 months ago, so unless we’re willing to move our GCC version to 8.3 JUST as easily, this seems like a horrific double standard. From: llvm-dev <llvm-dev-bounces at

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

I just landed these patches: commit c55051eea5d3cd57abfd9727f519b670517704d9 Author: Louis Dionne <ldionne at apple.com> Date: Thu Jun 25 12:02:43 2020 -0400 [libunwind] Allow specifying custom Lit config files This is the libunwind counterpart of 0c66af970c80. commit 33c9c10d183371edc95fa936705bef56f55ab611 Author: Louis Dionne <ldionne at

One of the MSVC devs recently said they are pushing for getting cmake 3.17.0 in the next point release which is expected in May. https://www.reddit.com/r/cpp/comments/fluibz/_/fl2bpz1 On Wed, Apr 8, 2020, 21:51 Chris Tetreault via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Visual studio 2019 ships with CMake 3.15.5, which is pretty darn new IMO. > From what I can tell, CMake

Yeah, I don’t anticipate Windows posing problems. Also, it’s pretty common in Windows to just install software yourself, and CMake ships prebuilt binaries and an installer, so it’s pretty easy to get set up with it. Chris, I’m gonna reiterate a question of mine from an earlier email, since you may have thoughts on it: * If we want to limit ourselves to CMake versions supported by LTS releases of

Hi All, Throwing a couple of comments in: Chris's position here has a lot of good points and we want to make sure we're not raising the barrier too high. I definitely want to be able to push ahead with our versions of tools; being able to update quickly is one of the hallmarks of the llvm project. That said, binary packages that can be updated are a minimal first step IMO. I'd really

[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

On Wed, Mar 4, 2020 at 9:42 AM Louis Dionne <ldionne at apple.com> wrote: > > > On Mar 4, 2020, at 12:13, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > On Wed, Mar 4, 2020 at 8:14 AM Louis Dionne <ldionne at apple.com> wrote: > >> Mehdi, Chris & others, >> >> I guess I did not express the main reasons for wanting to switch over

> On Mar 3, 2020, at 17:16, Shoaib Meenai <smeenai at fb.com> wrote: > > `arc patch` should preserve the author information in the original commit, if there was any. At least it has in my experience. Yes, but I think people can upload raw patches to Phabricator without using `arc diff`. I know I ran into one of these just last week where I used Johannes' script (thanks!) and

What about helping the user: https://reviews.llvm.org/D83995 ? (can also improve the detection to point at the apt repo on Ubuntu if needed) -- Mehdi On Thu, Jul 16, 2020 at 6:21 PM James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Please, no more waiting on CMake versions in distro LTS releases. We have > been *way* too conservative already, waiting this long.

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

I understand organization restrictions and old operating systems (I use CentOS 7 myself), but I’ll note that the only requirement for running a new CMake is the ability to download and untar a tarball; in particular, you don’t require sudo. (I understand that there may be restrictions around running arbitrary executables downloaded from the internet, which of course make sense, but I wanted to

On 2020-03-04, Louis Dionne via llvm-dev wrote: > > >> On Mar 4, 2020, at 12:13, Mehdi AMINI <joker.eph at gmail.com> wrote: >> >> >> >> On Wed, Mar 4, 2020 at 8:14 AM Louis Dionne <ldionne at apple.com <mailto:ldionne at apple.com>> wrote: >> Mehdi, Chris & others, >> >> I guess I did not express the main reasons for

I agree that’s valuable, but then it’s also important to pin down exactly what a “modern OS” is, and which ones we should keep in mind when we’re considering e.g. which CMake versions are feasible. (The same applies even more so to toolchain requirements, of course.) From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Reid Kleckner via llvm-dev <llvm-dev at

I am strongly in favor of increasing the minimum CMake version. I think we should NOT be waiting for the next LLVM release to do so, but should do so as soon as practical (e.g. maybe a month from now). A warning message emitted in CMake spam is not likely to help users very much, IMO. An entry in the release notes saying "This version of LLVM now requires CMake X.Y.Z." along with a link

> 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

On Wed, Mar 4, 2020 at 8:14 AM Louis Dionne <ldionne at apple.com> wrote: > Mehdi, Chris & others, > > I guess I did not express the main reasons for wanting to switch over very > well in my original message. > You original message was about “ commit attribution”, but now it is all about testing? Instead of jumping to a solution (pull-request) why not expressing the

> On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Okay, so we've had some discussion on this thread, and although some people (including me) would like a more aggressive policy, I believe the following will not get any objection (based on the thread). On April 23rd 2020, Ubuntu 20.04 LTS will ship with CMake 3.16.x. This will make the

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