similar to: [LLVMdev] [cfe-dev] is configure+make dead yet?

>From: David Röthlisberger <david at rothlis.net> >Subject: Re: [LLVMdev] [cfe-dev] is configure+make dead yet? > >If the following statement is true, then which build system to choose >is a no-brainer: >> cmake, while ugly, can be made to support all of our use cases. There >> are some use cases that autoconf+make can't support >-- Chandler Carruth, On 21

On 21 Jun 2012, at 01:19, Chandler Carruth wrote: > cmake, while ugly, can be made to support all of our use cases. There > are some use cases that autoconf+make can't support, So far I have assumed that "use cases that autoconf+make can't support" is referring to Windows support. (I am not a Windows user myself.) But the following two statements left me wondering: Are

Mason Wheeler wrote: >>From: David Röthlisberger <david at rothlis.net> >>Subject: Re: [LLVMdev] [cfe-dev] is configure+make dead yet? >> >>If the following statement is true, then which build system to choose >>is a no-brainer: > >>> cmake, while ugly, can be made to support all of our use cases. There >>> are some use cases that

Mason Wheeler <masonwheeler at yahoo.com> writes: >>If the following statement is true, then which build system to choose >>is a no-brainer: > >>> cmake, while ugly, can be made to support all of our use cases. There >>> are some use cases that autoconf+make can't support >>-- Chandler Carruth, On 21 Jun 2012, at 01:19 > > Unfortunately, >

On Wed, Jun 27, 2012 at 3:10 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > David Röthlisberger <david at rothlis.net> > writes: > > > On 21 Jun 2012, at 01:19, Chandler Carruth wrote: > >> cmake, while ugly, can be made to support all of our use cases. There > >> are some use cases that autoconf+make can't support, > > > > So far I

On Wed, Jun 20, 2012 at 5:13 PM, Nick Lewycky <nlewycky at google.com> wrote: > Is there anybody who is certain that our autoconf dependency needs to stay > around? Are there developers stuck on systems that don't have a recent > enough cmake in their most recent release, or maybe are using some features > from configure+make that the cmake build system doesn't

Is there anybody who is certain that our autoconf dependency needs to stay around? Are there developers stuck on systems that don't have a recent enough cmake in their most recent release, or maybe are using some features from configure+make that the cmake build system doesn't implement? If nobody pipes up, I might actually try actually removing it! Nick -------------- next part

On 28 Jun 2012, at 08:58, Jean-Daniel Dupas wrote: > It's a chicken and egg problems. Xcode users don't use cmake because it > generates poor Xcode projects. So what *do* XCode users do (to build llvm/clang)? Do they somehow set up XCode to build using the autoconf build system? Do they build llvm/clang outside of XCode? If the answer to either of the last two questions is

Albert Graef <Dr.Graef at t-online.de> writes: > On 06/21/2012 04:22 PM, Óscar Fuentes wrote: >> About the "many features" that cmake lacks, can you provide a list, >> please? > > Generally it works fairly well, but here are some differences to the > autoconf-based build I noticed: > > - No 'make uninstall'. That is a real deal breaker if you

On 06/22/2012 07:42 AM, David Röthlisberger wrote: > On 22 Jun 2012, at 00:08, Óscar Fuentes wrote: >> > Albert Graef <Dr.Graef at t-online.de> writes: >> > - libclang ends up as liblibclang.so (building clang along with LLVM). >>> >> Surely that's not intended? >> > >> > There was some discussion about this on the past, but I

>----- Original Message ----- >From: Óscar Fuentes <ofv at wanadoo.es> >You are misinformed. The LLVM CMake scripts can build LLVM/Clang as >shared libraries since almost day one. > >If you are thinking of Windows, well, there is a fundamental limitation >there, not an issue with CMake. Autoconf has a hack for building LLVM as >a single, monolithic dll while using

On 22 Jun 2012, at 00:08, Óscar Fuentes wrote: > Albert Graef <Dr.Graef at t-online.de> writes: > - libclang ends up as liblibclang.so (building clang along with LLVM). >> Surely that's not intended? > > There was some discussion about this on the past, but I can't recall all > the details. In any case, it is something easy enough to change. This should be

On 28 May 2012, at 16:46, Mikael Lyngvig wrote: > > Hi, > > I accidentally noticed the following line when building LLVM and Clang on Windows 7 x64 using Mingw64: > > Linking CXX shared library ..\..\..\..\bin\liblibclang.dll > > "Liblib" seems a bit overkill. FYI. See http://llvm.org/bugs/show_bug.cgi?id=12620 for links to several threads on the clang

On 6/27/2012 7:55 AM, David Röthlisberger wrote: > On 21 Jun 2012, at 01:19, Chandler Carruth wrote: >> cmake, while ugly, can be made to support all of our use cases. There >> are some use cases that autoconf+make can't support, > So far I have assumed that "use cases that autoconf+make can't support" > is referring to Windows support. (I am not a Windows

On Thu, Jun 21, 2012 at 10:43 AM, Charles Davis <cdavis at mymail.mines.edu>wrote: > > On Jun 20, 2012, at 6:19 PM, Chandler Carruth wrote: > > On Wed, Jun 20, 2012 at 5:13 PM, Nick Lewycky <nlewycky at google.com> wrote: > >> Is there anybody who is certain that our autoconf dependency needs to >> stay around? Are there developers stuck on systems that

2012/6/23 Joshua Cranmer <pidgeot18 at gmail.com>: > I decided to try recently to do one of my builds with cmake instead of > configure. The problem I hit is before I even try compiling in the first > place: cmake /src/llvm --help produces an extremely useless list of options, > so it's impossible to figure out how to configure it with cmake without > looking up online.

I used the make+configure build system when CMake broke with Xcode 4.3. I'm not sure how I would have built clang otherwise. Also, how does one 'install' clang with CMake? I see an install target in the CMake generated Xcode project, but Xcode doesn't have privileges necessary to run it. With make, after building you just do sudo make install. On Jun 20, 2012, at 8:13 PM, Nick

Manuel Klimek <klimek at google.com> writes: >> >> CMake generates gigantic project files for IDEs like Visual Studio and >> >> Xcode, which causes those IDEs to behavior very poorly, with long >> >> project load times and sluggish overall performance. It's a significant >> >> productivity problem. >> > -- Douglas Gregor, On 26

Hi Speaking about a good existing build system in python, there is waf : http://code.google.com/p/waf/ It is in my opinion far more better than cmake on any point (performance, flexibility, easy to use, ...) ... 2012/6/21 Jean-Daniel Dupas <devlists at shadowlab.org> > > Le 21 juin 2012 à 11:34, Manuel Klimek a écrit : > > On Thu, Jun 21, 2012 at 10:43 AM, Charles Davis

On 6/20/2012 11:00 PM, "C. Bergström" wrote: > On 06/21/12 12:47 PM, Chandler Carruth wrote: >> On Wed, Jun 20, 2012 at 5:13 PM, Nick Lewycky <nlewycky at google.com >> <mailto:nlewycky at google.com>> wrote: >> >> Is there anybody who is certain that our autoconf dependency needs >> to stay around? Are there developers stuck on