similar to: Fwd: [cfe-dev] Raising CMake minimum version to 3.4.3

cmake is a big dependency, but it doesn't seem to have many dependencies itself. They say it's just a C++ compiler and a make (not necessarily gnu). Probably there are one or two more than that :-) A shell, for a start; git or tar/gzip etc. The current *nix source tarball is 6.4 MB gzipped. Just for fun I grabbed it and tried building on four machines: - 3.4 GHz i7 3770 with Ubuntu

> > Replicating ExternalProject would be a lot of work... > One approach commonly used with CMake modules that change frequently upstream is for the project to keep a local copy and have a check in place to use CMake's version if new enough. For instance, in llvm's source tree: cmake/modules/ExternalProject.cmake: if(CMAKE_VERSION VERSION_LESS "3.5.1")

Most of the comments I have are actually very well captured by Chandler's email, so I'm not going to pile on. I do have a few things to add. 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 from https://CMake.org/download/

> 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

Meant to send this yesterday, but I want to remind everyone that we’re going to be raising the CMake minimum version to 3.4.3 next week. If you maintain bots please ensure that your bots are updated by end of day 5/29 so that we can move on 5/30 (next Monday). I have already heard from most bot owners either saying they had made the change, or scheduled to make it. If you have any questions or

On Wed, Apr 27, 2016 at 10:54 AM Renato Golin via cfe-dev < cfe-dev at lists.llvm.org> wrote: > On 27 April 2016 at 15:39, Rafael Espíndola <rafael.espindola at gmail.com> > wrote: > > Yes. It is a move to put linux developers in the same position as > > windows and OS X ones, which is a *very* reasonable thing to do. > > Apart from the fact that neither

All the MIPS buildbots are ready too. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of NAKAMURA Takumi via llvm-dev Sent: 25 May 2016 23:03 To: Chris Bieneman; llvm-dev at lists.llvm.org; cfe-dev at lists.llvm.org; lldb-dev at lists.llvm.org Subject: Re: [llvm-dev] [Attn: Bot Owners!] Raising CMake minimum version to 3.4.3 I am ready, regarding to, http://bb.pgr.jp/ On

I am ready, regarding to, http://bb.pgr.jp/ On Wed, May 25, 2016 at 5:54 AM Chris Bieneman <beanz at apple.com> wrote: > Meant to send this yesterday, but I want to remind everyone that we’re > going to be raising the CMake minimum version to 3.4.3 next week. > > If you maintain bots please ensure that your bots are updated by end of > day 5/29 so that we can move on 5/30

> To be clear, I'm not against moving the version up, I just want to > make sure that people understand that this is not *just* a version > upgrade, but a development philosophy move for all Linux developers > and production environments (of which we have plenty). This move was > proposed before and was rejected for the reasons I pointed out: > maintenance. Yes. It is a move

Hans, I have posted a complete patch for solving the linkage issues with LLVM_LINK_LLVM_DYLIB on Phabricator at http://reviews.llvm.org/D16945. The bulk of the fix the simple changes of... Index: cmake/modules/AddLLVM.cmake =================================================================== --- cmake/modules/AddLLVM.cmake (revision 259743) +++ cmake/modules/AddLLVM.cmake (working copy) @@

I'm not sure if they are doing an x86 to IA64 cross compile, but in any event I'm going to guess they may need an ancient version to avoid any C++11 dependencies. In terms of IA64 compilers you have afaik 3 choices HP compiler, Open64 and Intel? (Does gcc still support it and how up-to-date or EOL is the Intel compiler IA64 support?) I really hope nobody decides not to move to a more

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

On Fri, Jan 30, 2015 at 6:51 PM, Chris Bieneman <cbieneman at apple.com> wrote: > +Alex Bradbury > > Sounds to me like we have no known users still on VS 2012. > > So, how about we plan to move forward again with Chandler’s proposal for making this transition. For those who don’t want to dig through to the beginning here’s the basic plan: > > 1) Loop in cfe-dev and

Sorry for the late response. You should check out CMAKE_TOOLCHAIN_FILE logic for Android platform - IIRC build rules for Android are much simpler than for Darwin/Linux, and assume that build tree will be properly configured to build a single compiler-rt runtime for a specific triple. Probably this is the approach you want to eventually use for another platforms. Also check out

Starting a new thread to loop in cfe-dev and lldb-dev. For those not following along there has been a thread on llvm-dev about moving the minimum required Visual Studio version to 2013. The motivating reason is this will allow us to take advantage of a bunch of C++11 features that are not supported by MSVC 2012. According to MSDN (http://msdn.microsoft.com/en-us/library/hh567368.aspx) the list is:

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

Galina and Takumi, Are we ready to update the minimum required version to 2.8.12.2? -Chris > On Feb 12, 2015, at 2:35 PM, Chris Bieneman <beanz at apple.com> wrote: > > Chandler's feedback was that we should go to 2.8.12.2 instead of 3.0 because of Ubuntu's LTS release. > > -Chris > > > > On Feb 12, 2015, at 11:29 AM, Galina Kistanova <gkistanova

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 Mon, Feb 8, 2016 at 12:45 PM, Hans Wennborg <hans at chromium.org> wrote: > Chris Bieneman is probably your best bet, and maybe also Dan Liew. > Hans, My current, and hopefully final, revision of the proposed patch is simplified and reworked to solve the problem entirely from cmake without touching the the llvm-build python scripts. Basically, the new fix for avoiding the