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 -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120620/910fa78b/attachment.html>
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 implement? > > If nobody pipes up, I might actually try actually removing it! >There are definitely missing features in cmake. I'm actually working on adding one of them: support for compiler-rt. There are likely some others. That said, I actually agree -- I think that 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 I'd rather we just pick cmake and bang on it until it works the way we want. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120620/77775c24/attachment.html>
On 6/20/2012 5:19 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 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! > > > There are definitely missing features in cmake. I'm actually working on > adding one of them: support for compiler-rt. There are likely some others. > > That said, I actually agree -- I think that 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 I'd rather we just pick cmake and bang > on it until it works the way we want. >Please dont remove it yet. I'm relying on configure's '--enable-libcpp' flag to compile LLVM/clang using clang++ and libc++. I couldnt find an equivalent using cmake. Please see my mails titled "Compiling libc++ from within llvm (3.1)" and "Build llvm/clang with cmake vs configure produces different set of artifacts". If you have any suggestions, I'm most willing to try it out. I dont know enough about CMake but I tried to go through the cmake build files. Thanks, ashok
On 06/21/2012 02:13 AM, Nick Lewycky 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 nobody pipes up, I might actually try actually removing it!Hi Nick, I don't see a reason to keep it, but I would like you to check that all buildbots are moved over to cmake. The Polly buildbots are, but I have doubts about the other buildbots. Tobi
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 implement? > > If nobody pipes up, I might actually try actually removing it! >FWIW, I'm also under the impression that Apple's internal release process depends on configure+make as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120620/9d6d66cc/attachment.html>
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 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! >> >> >> FWIW, I'm also under the impression that Apple's internal release >> process depends on configure+make as well. > clang/llvm are advertised as being independent of Apple. There's a ton > of companies using the project, but we should let them speak-up if they > *really* need it to stay around. > > +1 for removing autoconf depI posted earlier but seems it didnt catch anybody's attention. Please dont remove it yet. I'm relying on configure's '--enable-libcpp' flag to compile LLVM/clang using clang++ and libc++. I couldnt find an equivalent using cmake. Please see my mails titled "Compiling libc++ from within llvm (3.1)" and "Build llvm/clang with cmake vs configure produces different set of artifacts". If you have any suggestions, I'm most willing to try it out. I dont know enough about CMake but I tried to go through the cmake build files. Thanks, ashok
Hi Nick,> 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!most of my builders are using configure + make, so will need to be converted. Fortunately, all the build machines seem to have cmake installed. Ciao, Duncan.
Hi Nick,> If nobody pipes up, I might actually try actually removing it!I think cmake system lacks many features of autoconf system. In addition to already said thing, I think the major missing thing is cross-compilation support. You can easy cross-compile llvm/clang via standard --build/--host/--target flags. If you will show that this will be possible by cmake - then everything will be fine :) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
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 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! >>> >>> >>> FWIW, I'm also under the impression that Apple's internal release >>> process depends on configure+make as well. >> clang/llvm are advertised as being independent of Apple. There's a ton >> of companies using the project, but we should let them speak-up if they >> *really* need it to stay around. >> >> +1 for removing autoconf dep > > I posted earlier but seems it didnt catch anybody's attention. > > Please dont remove it yet. I'm relying on configure's '--enable-libcpp' > flag to compile LLVM/clang using clang++ and libc++. I couldnt find an > equivalent using cmake. Please see my mails titled "Compiling libc++ > from within llvm (3.1)" and "Build llvm/clang with cmake vs configure > produces different set of artifacts". > > If you have any suggestions, I'm most willing to try it out. I dont know > enough about CMake but I tried to go through the cmake build files. > > Thanks, > ashokI managed to use: CC=clang CXX=clang++ CXXFLAGS="-stdlib=libc++ -I <libcxxdir..." cmake... to cause it to use clang++ with libc++ to build LLVM/clang. But now I run into bug 10646 (http://llvm.org/bugs/show_bug.cgi?id=10646). Can somebody comment on when the patch will be available on trunk. I can apply the patch to my local copy but would like to avoid local changes. tia, ashok
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 the cmake build system doesn't implement? > > If nobody pipes up, I might actually try actually removing it! > > There are definitely missing features in cmake. I'm actually working on adding one of them: support for compiler-rt. There are likely some others. > > That said, I actually agree -- I think that 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 I'd rather we just pick cmake and bang on it until it works the way we want.Now hold on there. I thought Daniel was supposed to be working on a new build system, based almost entirely in Python, specifically because he thought CMake was, uh... inadequate (to say the least). I've CC'd him in the hopes of getting his opinion. On the other hand, +1 for gutting autoconf. I hate it, and it needs to die. Chip P.S. -- Chandler, please increase the font size in your mail client. It's very small and hard to read. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/55d360e9/attachment.html>
Anton Korobeynikov <anton at korobeynikov.info> writes:> I think cmake system lacks many features of autoconf system. In > addition to already said thing, I think the major missing thing is > cross-compilation support. > You can easy cross-compile llvm/clang via standard > --build/--host/--target flags. If you will show that this will be > possible by cmake - then everything will be fine :)Anton, I've posted this information several times on this list, IIRC some of them after you claimed that cmake can't cross-compile, so I hope this is cleared once and for all: http://llvm.org/docs/CMake.html#cross About the "many features" that cmake lacks, can you provide a list, please? (supposing those features actually are useful for LLVM developers. I know that the configure+make build does things missing on the cmake build, but the later does things missing on the former too.) I asked for that list of missing features multiple times on this list, and nobody ever came with anything.
On 6/20/2012 8:13 PM, Nick Lewycky 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? >Note that the LLVM documentation (e.g., <http://llvm.org/docs/GettingStarted.html>) treats the configure-and-make build system as canonical, and I recall when I first used the cmake build system, I was told that one thing I was trying to do was unsupported in the cmake build (I've forgotten what it was though). -- Joshua Cranmer News submodule owner DXR coauthor -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/4adc4acf/attachment.html>
On 06/21/2012 07:47 AM, Chandler Carruth wrote:> FWIW, I'm also under the impression that Apple's internal release > process depends on configure+make as well.As do the Debian/Ubuntu packaging scripts. I'm sure that they can be changed to use the cmake build system instead, but someone will have to do the work. This issue comes up every once in a while. I'm sure that there are other LLVM users who prefer autoconf over cmake and therefore appreciate that LLVM still supports it. Of course, that's a matter of preference and experience and I can understand that the LLVM developers have better things to do than supporting two separate build systems. I just wished that the favoured alternative wasn't cmake. ;-) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag
On Wed, 20 Jun 2012 17:13:41 -0700, Nick Lewycky said:>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?There's this: 'address sanitizer does not work if clang is built with CMake' <http://llvm.org/bugs/show_bug.cgi?id=12272> (PS: +1 for switching to CMake.) -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada
Hi Nick, On Wed, Jun 20, 2012 at 7: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 nobody pipes up, I might actually try actually removing it!All my scripts are using configure + make, as on my old linux distro cmake was not installed by default. I now have cmake installed, although I have not tried yet to cross-compile with cmake. I would need some time to adapt my scripts and make sure I can use cmake for my cross-compiles. Thanks, Sebastian -- Qualcomm Innovation Center, Inc is a member of Code Aurora Forum
FWIW, I felt some pain moving from autoconf to cmake. However, once I got familiar with controlling camke a little better and editing CMakeLists.txt, the comfort grew and I came to appreciate its advantages over autoconf. CMakeLists.txt are far easier to create and to maintain and I wouldn't really mind if autoconf would be deprecated here. I understand that the transition would be perhaps painful to many and at the same time, but, except for any particular situations that cmake doesn't cover, I think that it would be for the better. -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum On 06/20/12 19:13, Nick Lewycky 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 nobody pipes up, I might actually try actually removing it! > > Nick > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Wed, Jun 20, 2012 at 05:13:41PM -0700, Nick Lewycky 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?I don't care much about make, but configure is important for the bootstrap of LLVM and Clang on NetBSD. Requiring cmake (or Python for that matter) would be very heavy. Joerg
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 nobody pipes up, I might actually try actually removing it!I think this is premature, although I consider it a worthy goal. Right now, the only motivation we have for removing "configure+make" is that we don't like having two build systems, but that's not good enough. Some things that CMake needs to do well for it to become the only way to build LLVM/Clang: - Optionally build and install compiler-rt - Optionally build and install libc++ - Ease-to-use cross-compilation support - Documentation to make it easy to understand how to do the above - LLDB? - LLVM testsuite support And some value-add that might make CMake motivating for others: - Easy bootstrap - Build packages/installers - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/fbb75073/attachment.html>
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 some >> features from configure+make that the cmake build system doesn't >> implement? >> >> If nobody pipes up, I might actually try actually removing it! > > I think this is premature, although I consider it a worthy goal.I agree, I just had no way of knowing how premature. There was no list, people aren't in the habit of filing bugs for missing features and I haven't seen any migration-looking commits landing in a while.> Right now, > the only motivation we have for removing "configure+make" is that we don't > like having two build systems, but that's not good enough.I want to add support for --compress-debug-sections to the assembler. That means that I'd like to add a new optional dependency (on zlib) to llvm, and couldn't. The problem is that I can't run AutoRegen.sh even after searching for the right versions of all the autoconfy bits. Debian has a "snapshot" server with every version of every package they've ever had, and even that failed me; I found autoconf 2.59 and 2.61, but no 2.60.>From my point of view, that's a crisis. I'm sure we'll figuresomething out, but right now I'm thinking "I can't do my job because of the build system".> Some things that CMake needs to do well for it to become the only way to > build LLVM/Clang: > - Optionally build and install compiler-rt > - Optionally build and install libc++ > - Ease-to-use cross-compilation support > - Documentation to make it easy to understand how to do the above > - LLDB? > - LLVM testsuite support > > And some value-add that might make CMake motivating for others: > - Easy bootstrap > - Build packages/installersThanks for this list! Nick
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 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! > > > I think this is premature, although I consider it a worthy goal. Right > now, the only motivation we have for removing "configure+make" is that we > don't like having two build systems, but that's not good enough. >Here here. Thanks for writing up this detailed and accurate response.> Some things that CMake needs to do well for it to become the only way to > build LLVM/Clang: > - Optionally build and install compiler-rt > - Optionally build and install libc++ >FYI, I'm currently in-flight working on the first of these, and planning to work on the second afterward.> - Ease-to-use cross-compilation support > - Documentation to make it easy to understand how to do the above > - LLDB? > - LLVM testsuite support >I think David might be interested in this. However, the way LNT is structured, I don't think this is a requisite: it is now much more common to build the testsuite independently of llvm/clang, and hand it a set of pre-built binaries. And some value-add that might make CMake motivating for others:> - Easy bootstrap > - Build packages/installers >A couple more: - Support for ninja if you happen to have it (and no cost if you don't) gives you faster rebuilds. - Slightly better support for the new Tooling infrastructure. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/74ce2da6/attachment.html>
On Jun 21, 2012, at 12:21 PM, Douglas Gregor 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 some features from configure+make that the cmake build >> system doesn't implement? >> >> If nobody pipes up, I might actually try actually removing it! > > I think this is premature, although I consider it a worthy goal. > Right now, the only motivation we have for removing "configure+make" > is that we don't like having two build systems, but that's not good > enough. > > Some things that CMake needs to do well for it to become the only > way to build LLVM/Clang: > - Optionally build and install compiler-rt > - Optionally build and install libc++ > - Ease-to-use cross-compilation support > - Documentation to make it easy to understand how to do the above > - LLDB? > - LLVM testsuite support > > And some value-add that might make CMake motivating for others: > - Easy bootstrap > - Build packages/installersIn addition, it also needs to be published that make is deprecated and support will be removed in the future. My impression of what the docs say now is that it's pretty neutral, implying that the choice is up to the user. If the direction is 'cmake only', that should be made clear in advance. It sounds like the collective will is clear, so perhaps 'now' is the appropriate time. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/7e3602c8/attachment.html>
On 6/21/2012 1:21 PM, Douglas Gregor wrote:> > On 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 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! > > I think this is premature, although I consider it a worthy goal. Right > now, the only motivation we have for removing "configure+make" is that > we don't like having two build systems, but that's not good enough. > > Some things that CMake needs to do well for it to become the only way > to build LLVM/Clang: > - Optionally build and install compiler-rt > - Optionally build and install libc++ > - Ease-to-use cross-compilation support > - Documentation to make it easy to understand how to do the above > - LLDB? > - LLVM testsuite support > > And some value-add that might make CMake motivating for others: > - Easy bootstrap > - Build packages/installersI 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. Compare this to /src/llvm/configure --help, where I can see what the default build will look like and also how I can tweak it for what I want. Even the online documentation is kind of crappy in this regard: e.g., LLVM_TARGETS_TO_BUILD doesn't tell you *which* targets you can build in the first place. I'm sure most people who do a lot of cmake know these settings by the back of their hand, but if you're like me and totally clueless when it comes to cmake, it's downright confusing. -- Joshua Cranmer News submodule owner DXR coauthor -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120622/2bd6cc05/attachment.html>
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 people actually using LLVM's CMake build system on Windows? Or are they using the autoconf system with something like Cygwin / MinGW?> CMake is not even capable of [...] setting up project files to build > LLVM as a DLL so they can build a compiler atop it-- Mason Wheeler, On 27 Jun 2012, at 13:29> 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 Jun 2012, at 17:42 (on thread "CMake Question: Do we need to support stand-alone builds?") --Dave.
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 have assumed that "use cases that autoconf+make can't support" > > is referring to Windows support. (I am not a Windows user myself.) > > CMake was introduced for supporting Visual Studio, because autoconf is > useless for that toolset and the hand-made VS project files that were in > place at the time were inconvenient for several reasons. > > > But the following two statements left me wondering: Are people actually > > using LLVM's CMake build system on Windows? Or are they using the > > autoconf system with something like Cygwin / MinGW? > > > >> CMake is not even capable of [...] setting up project files to build > >> LLVM as a DLL so they can build a compiler atop it > > -- Mason Wheeler, On 27 Jun 2012, at 13:29 > > See my reply to that assertion on my other message. > > >> 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 Jun 2012, at 17:42 > > (on thread "CMake Question: Do we need to support stand-alone builds?") > > I don't know if Doug measured the impact on Visual Studio performance > specifically caused by CMake, compared to non-CMake project > files. AFAIK, CMake is the only existing option for working with Visual > Studio, so I have no idea of what's the point of Doug here. >Doug specifically mentioned Xcode. For VS CMake does support project()s which you can open by themselves in the IDE, including all dependencies. Cheers, /Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120627/6c0a23af/attachment.html>
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 Jun 2012, at 17:42 >> > (on thread "CMake Question: Do we need to support stand-alone builds?") >> >> I don't know if Doug measured the impact on Visual Studio performance >> specifically caused by CMake, compared to non-CMake project >> files. AFAIK, CMake is the only existing option for working with Visual >> Studio, so I have no idea of what's the point of Doug here. >> > > Doug specifically mentioned Xcode.... and VS.> For VS CMake does support project()s > which you can open by themselves in the IDE, including all dependencies.So it doesn't for Xcode? CMake comes with an Xcode generator which had (has?) several nasty limitations. Time ago some Apple people were in touch with the CMake developers and, IIRC, patches were proposed. I guess that the Xcode generator still lacks in quality.
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 Lewycky 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 nobody pipes up, I might actually try actually removing it! > > Nick > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120704/df05633e/attachment.html>
On Wed, Jul 4, 2012 at 5:16 PM, Seth Cantrell <seth.cantrell at gmail.com> wrote:> 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.Redundancy in case of breakage is hardly a good reason to maintain two parallel build systems. Tim.
On Wed, Jul 4, 2012 at 6:16 PM, Seth Cantrell <seth.cantrell at gmail.com>wrote:> 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. >Couldn't you generate Makefiles from CMake?> > 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. >Same thing here... Cheers, /Manuel> On Jun 20, 2012, at 8:13 PM, Nick Lewycky 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 nobody pipes up, I might actually try actually removing it! > > Nick > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120705/09c6409d/attachment.html>