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

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

On 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 implement? > > If

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

On 6/20/2012 11:55 PM, Ashok Nalkund wrote: > 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

Le 21 juin 2012 à 11:34, Manuel Klimek a écrit : > 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?

On Thu, Jun 21, 2012 at 10:21 AM, Douglas Gregor <dgregor at apple.com> wrote: > > On 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

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

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 don't have a recent enough cmake in their most recent release, or maybe are using some features from configure+make that

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

On 21/06/2012, Douglas Gregor <dgregor at apple.com> wrote: > > On 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

On Feb 3, 2015, at 1:40 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2015 Feb 3, at 13:26, Chris Bieneman <beanz at apple.com> wrote: >> >> >>> On Feb 3, 2015, at 1:06 PM, Jonathan Roelofs <jroelofs.lists at gmail.com> wrote: >>> >>> >>> >>> On 2/3/15 12:08 PM, Chris Bieneman wrote:

Hi All, I fear starting another centi-thread on this but I'll give it a shot. We're currently supporting two build systems which is definitely one more than we (or I) want to support. I don't know of any support in autoconf past the --host/--build/--target case that's not supported in cmake. I'll send out an assertion here that this support isn't necessary and any system

On 22 May 2013 16:14, Eric Christopher <echristo at gmail.com> wrote: > Hi All, > > I fear starting another centi-thread on this but I'll give it a shot. > > We're currently supporting two build systems which is definitely one > more than we (or I) want to support. > > I don't know of any support in autoconf past the > --host/--build/--target case

> On Feb 3, 2015, at 1:06 PM, Jonathan Roelofs <jroelofs.lists at gmail.com> wrote: > > > > On 2/3/15 12:08 PM, Chris Bieneman wrote: > >> Other issues not tracked by bugs: >> >> * CMake builds for libc++? > Can you elaborate... what do you mean by this? AFAIK this already works. Duncan made a comment on IRC about being libc++, but I’m not aware

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

Resending :(. Any pointers? tia On 5/21/2012 2:46 PM, Ashok Nalkund wrote: > On 5/21/2012 11:15 AM, Nick Lewycky wrote: >> Ashok Nalkund wrote: >>> Resending, any pointers? I demangled the symbol and it turns out to be: >>> std::__1::locale::use_facet(std::__1::locale::id&) const >> >> My guess is that you've got a .bc file produced on a mac using

On Thu, Jun 21, 2012 at 12:50 AM, Ashok Nalkund <ashoknn at qualcomm.com> wrote: > On 6/20/2012 11:55 PM, Ashok Nalkund wrote: >> 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

Ashok Nalkund wrote: > > Resending :(. Any pointers? Fundamentally the issue is that the system linker is supposed to define __dso_handle when linking, but since there is no system linker between your build of the .bc files and running lli, nobody has defined it. It seems reasonable to me that lli should define __dso_handle if it's declared in the module. You could module

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