similar to: RFC: Updating to CMake 3.15.0

+1 to bumping cmake version and cleaning build system somewhat. On Tue, Oct 29, 2019 at 8:23 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 10/29/2019 10:10 AM, Chris Bieneman via llvm-dev wrote: > > At the LLVM Developer Meeting on October 23rd we held a CMake roundtable. One of the items we discussed was adopting a more regular timeline for CMake

On Tue, Oct 29, 2019 at 8:40 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Oct 29, 2019 at 10:28 AM Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> +1 to bumping cmake version and cleaning build system somewhat. >> >> On Tue, Oct 29, 2019 at 8:23 PM Tom Stellard via llvm-dev >> <llvm-dev at

On Tue, Oct 29, 2019 at 12:48 PM Jean-Daniel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > Le 29 oct. 2019 à 19:00, Roman Lebedev via llvm-dev < > llvm-dev at lists.llvm.org> a écrit : > > On Tue, Oct 29, 2019 at 8:40 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > > On Tue, Oct 29, 2019 at 10:28 AM Roman Lebedev via llvm-dev

On Tue, Oct 29, 2019 at 3:29 PM James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote: > CMake is extremely easy for developers to download and build locally -- or > just download binaries for if you like, too. > Is there any script we can/would provide to help with this? Or is it so simple that two lines in the "getting started" instructions would be enough?

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

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 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

Now that 3.8 is imminently branching with the newly deprecated autoconf I think it is time to propose a process and timeline for removing autoconf support from trunk. At this point I believe there should be no users of autoconf for Clang and LLVM that are not supported by CMake, so I would like to propose dropping autoconf support from the cfe and llvm repositories on January 26th (two weeks from

> On Apr 27, 2016, at 11:17 AM, Renato Golin <renato.golin at linaro.org> wrote: > > On 27 April 2016 at 18:41, Chris Bieneman <beanz at apple.com> wrote: >> Renato, in your most recent email you comment about differentiating *stable* vs random versions of CMake built from source. I believe as a community our recommendation should be that people download CMake sources

Chris, We have upgrade our bots (both internal and external) to CMake 3.5.2. So we are good to go. -Mike On Tue, May 3, 2016 at 12:29 PM, Chris Bieneman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Renato, > > This approach sounds great to me. > > Chris M let me know separately that GreenDragon is on CMake 3.5. > > I belive Galina and Takumi maintain the

Tobias, My hope is that now is the time when owners of bots using autoconf will be migrating them to CMake, however I don’t expect that all the autoconf bots need to be migrated. My strong suspicion is that many of the autoconf bots that are remaining have CMake-equivolent bots already, so they can just be deactivated. -Chris > On Jan 14, 2016, at 6:06 AM, Tobias Grosser <tobias at

Over the past few years the LLVM CMake build system has gained a lot of new features, which have powered new workflows and capabilities. This development has largely been individual efforts without focus or long-term direction. The build system is of incredible importance to LLVM as it is a primary interface for contributors to build and test their changes. This year, LLVM is making a huge

> On Oct 30, 2019, at 12:02 PM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Here's an argument for why to *lower* the minimum supported CMake version: No offense, but that isn't going to happen. > > LLVM is a compiler backend. LLVM is *much* more than a compiler backend. Using LLVM as a compiler backend is one use of LLVM. It is also a JIT

Actually forward to LLVM-dev because I obviously don’t know how email works… -Chris > Begin forwarded message: > > From: Chris Bieneman via cfe-dev <cfe-dev at lists.llvm.org> > Subject: [cfe-dev] Raising CMake minimum version to 3.4.3 > Date: April 26, 2016 at 3:01:23 PM PDT > To: cfe-dev <cfe-dev at lists.llvm.org>, llvm-dev at lists.apple.com > Cc: Galina

Dear All, On Wednesday, October 23 at 5 pm we will have a roundtable about LLVM's participation in GSoC and similar programs: http://llvm.org/devmtg/2019-10/#round The list of topics includes: - Overall organization of the project (timeline, ideas, etc) - Ideas lists - Lessons learned from past projects More topics for discussion are welcome! -- With best regards, Anton Korobeynikov

Hi, I'm interested in GSOC in general, but I missed this roundtable unfortunately. Any summary from this session? Thanks, -- Mehdi On Mon, Oct 21, 2019 at 7:19 PM Vassil Vassilev via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Round table on GSoC is a very good idea. Thanks for organizing! > > -- Vassil > On 10/22/19 12:51 AM, Anton Korobeynikov via cfe-dev wrote:

I have moved onto the next phase and committed r229185, which makes VS2013 our minimum version. I will revert if issues arise, and we can rinse and repeat as necessary. Once it sticks for a bit I’ll update the docs too. -Chris > On Feb 9, 2015, at 10:07 AM, Chris Bieneman <beanz at apple.com> wrote: > > I agree with Aaron, this should not be a blocker because the workaround is

The purpose of this thread was to propose removing configure on January 26th. There have been no objections, so I’m assuming that timeline is acceptable. -Chris > On Jan 15, 2016, at 5:54 AM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/15/2016 5:05 AM, Daniel Sanders via llvm-dev wrote: >>> One issue that I believe has not yet been

I'm not sure what benefit that would provide. For most developers they already have configured build directories and if their CMake is too old they are going to do a `git pull` and all of a sudden their build fails to configure. Then they go fetch a new CMake. Not sure a bootstrap script really helps with that. Especially since the CMake git repository contains one, and many people might

> On Jan 12, 2016, at 9:39 AM, Reid Kleckner <rnk at google.com> wrote: > > Sounds like a plan. > > Should we leave behind a simple ./configure script that checks for cmake, and if present, runs something like 'cmake -G"Unix Makefiles" .'? I think it's nice if the "standard" Unix way of building with "./configure && make"