similar to: [RFC] Removing autoconf from trunk

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

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

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

A thread was started over the summer to discuss the timeline for bumping LLVM up to Visual Studio 2015 to enable the use of various new language features. Currently the ETA for this is sometime in mid-October, so within 2-3 weeks. With this happening imminently, I thought it would be worth tossing this out there and seeing what people think. With VS on 2015, the major lagging compiler is going

> One issue that I believe has not yet been addressed is to move our > existing buildbots to cmake. Looking at the config/builders.py a lot of > them have already been moved, but there seem to still be a couple that > did not yet switch. Did anybody an analysis regarding which bots still > need to be updated? We have one that's still on autoconf (llvm-linux-mips) but it should

Sent from my iPhone > On Oct 31, 2014, at 17:40, Steve King <steve at metrokings.com> wrote: > >> On Fri, Oct 31, 2014 at 3:08 PM, Tom Stellard <tom at stellard.net> wrote: >> - Is there any technical reason why the remaining autoconf users can't switch >> to CMake? > > Last time I tried, the CMake build was missing some pieces required > for

> On Oct 3, 2016, at 10:38 AM, Justin Bogner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> writes: >> A thread was started over the summer to discuss the timeline for bumping >> LLVM up to Visual Studio 2015 to enable the use of various new language >>

Any chance I could beg a couple of week extension on the removal? We're tracking ToT and ran into some minor snags getting switched over to cmake. Having an extra couple of weeks would be really useful. Philip On 01/07/2016 10:54 AM, Eric Christopher via llvm-dev wrote: > They're deprecated in 3.8. Chris and I are making plans for when > (after branch) the removal happens. >

So, we’ve had this conversation a few times, and I wanted to coalate a status report for all the interested parties. Here's the outstanding work and my (not necissarily correct) view of the status and importance of each one: * Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable - There are patches on the bug that we should review, test, and land * Bug 14109 - CMake

Hi Chris, On 14 Mar 2015, at 21:42, Chris Bieneman wrote: > Just out of curiosity. The community generally seems to be moving away from autoconf toward CMake. Is there a reason why you need the autoconf build bad enough to support it out-of-tree? The reasons a short-term and boring engineering/project-related, rather than ideological. We all agree that one well-maintained build system is

Sorry I’m a little late to this thread. There has been some discussion about using CMake to generate shared libraries. Since I’ve done some patches in this area recently I thought I’d take a minute to explain the current state of things. Historically LLVM’s CMake build system has been able to produce shared libraries for each of the llvm static libraries. My patch (r220490) added the llvm-shlib

Hi, I would like to propose deprecating the autoconf build system at some point in the future. Maintaining two build systems is a hassle not only for this project, but also for other projects that use LLVM and have to deal with the slight differences in output between the two build systems. It seems like most people are using CMake at this point, so my questions to the community are: - Is

On 03/10/2015 06:38 PM, Mehdi Amini wrote: > Hi Tobias, [...] >>> Also, could we just limit the cmake version on windows builds? In the >>> end on linux cmake 2.8.9 works great. >> >> Rafael asked if updating the bot is not an option. It indeed is an option, but requires cmake to be manually downloaded and installed instead of using the available packages.

> Date: Thu, 1 Mar 2001 08:52:09 -0500 (EST) > From: Walter Tautz <wtautz@math.uwaterloo.ca> Re: [Rd] timeline for R-1.2.x where x>1? Just curious as I am looking to update our installation. You can always find the current plans on developer.r-project.org. That says The latest release of R was 1.2.2 on February 26th, 2001. We might have a 1.2.3 release mainly with fixes

> 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

Hi LLVMDev, Since my last update we’ve landed patches for these issues: * Bug 14200 - -fno-rtti not in cxxflags given by llvm-config * Bug 23746 - test-suite lacks CMake support * Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not compatible with ldconfig On my last thread Jonathan Roelofs pointed out that there is a workaround for Bug 21568 (Cannot add rpath), so I’m making it

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

Both Release and $CONFIG tblgen are built but the Release one is always used. At least with Visual C++ the Release tblgen is much faster than the Debug one. 2015-05-29 9:37 GMT+03:00 Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>: > Do they really allways put them into Release/bin or rather $<CONFIG>/bin? > > > > -- >

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 upgrades. During the roundtable there was overwhelming support for upgrading CMake, and support for treating CMake differently than how we treat upgrading host compilers. Historically we've taken into account recent versions of Visual Studio,

I sent out a patch for review. http://reviews.llvm.org/D10102 <http://reviews.llvm.org/D10102> -Chris > On May 28, 2015, at 9:48 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > > Thanks! > > 2015-05-28 18:56 GMT+03:00 Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>>: > >> On May 28, 2015, at 8:37 AM, Yaron Keren