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 that needs it can instead move to: build native clang build next clang with some target that supplies a sysroot and a -target option to the native clang Can anyone see good a reason not to move to cmake as our only build configuration system and drop future support for autoconf + makefiles now that 3.3 has branched? -eric
On Wed, May 22, 2013 at 4:14 PM, 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 that's not supported in cmake. I'll send > out an assertion here that this support isn't necessary and any system > that needs it can instead move to: > > build native clang > build next clang with some target that supplies a sysroot and a > -target option to the native clang > > Can anyone see good a reason not to move to cmake as our only build > configuration system and drop future support for autoconf + makefiles > now that 3.3 has branched?I definitely think this is a good idea, and a very timely suggestion. Once we have collected a list of remaining problems, we should have plenty of time to address them all such that we can remove the autoconf build system for 3.4. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130522/d2579e2a/attachment.html>
[Adding cfe-dev to CC, not everyone there is subscribed to llvmdev] On Wed, May 22, 2013 at 4:22 PM, Richard Smith <richard at metafoo.co.uk>wrote:> On Wed, May 22, 2013 at 4:14 PM, 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 that's not supported in cmake. I'll send >> out an assertion here that this support isn't necessary and any system >> that needs it can instead move to: >> >> build native clang >> build next clang with some target that supplies a sysroot and a >> -target option to the native clang >> >> Can anyone see good a reason not to move to cmake as our only build >> configuration system and drop future support for autoconf + makefiles >> now that 3.3 has branched? > > > I definitely think this is a good idea, and a very timely suggestion. Once > we have collected a list of remaining problems, we should have plenty of > time to address them all such that we can remove the autoconf build system > for 3.4. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130522/edab5e3c/attachment.html>
----- Original Message -----> 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 > that needs it can instead move to: > > build native clang > build next clang with some target that supplies a sysroot and a > -target option to the native clang > > Can anyone see good a reason not to move to cmake as our only build > configuration system and drop future support for autoconf + makefiles > now that 3.3 has branched?We still need to add CMake support to the test suite, right? -Hal> > -eric > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
CMake is just a makefile (or <insert build system here>) generator. So something like cmake <stuff>; make check-all works already. Or did you have something else in mind? -eric On Wed, May 22, 2013 at 4:28 PM, Hal Finkel <hfinkel at anl.gov> wrote:> ----- Original Message ----- >> 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 >> that needs it can instead move to: >> >> build native clang >> build next clang with some target that supplies a sysroot and a >> -target option to the native clang >> >> Can anyone see good a reason not to move to cmake as our only build >> configuration system and drop future support for autoconf + makefiles >> now that 3.3 has branched? > > We still need to add CMake support to the test suite, right? > > -Hal > >> >> -eric >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>
On May 22, 2013, at 5:14 PM, Eric Christopher wrote:> Hi All, > > Can anyone see good a reason not to move to cmake as our only build > configuration system and drop future support for autoconf + makefiles > now that 3.3 has branched?I can think of several: - When the Clang CMakefiles go to build compiler-rt (if present), they use the compiler used to build Clang and not the newly-built Clang itself. This one is fairly minor (I think), but it does make CMake as it stands untenable for cross-compilation builds where the host and target are not the same--the compiler-rt libs get built for the *host* and not for the *target*. But as you pointed out, there is a workaround (albeit a clumsy workaround). Just something to keep in mind if and when you do move to CMake. - CMake is not available everywhere. Bourne shells are*. As I recall, this is the reason autoconf generates shell scripts: because nearly every operating system out there comes with a shell! Even the old-timey MPW development environment for the Mac came with one! (* Even Windows comes with a shell, though it's not a Bourne shell but something else entirely with a few constructs borrowed from the Bourne shell's predecessor, the Thompson shell. But I only care about Windows inasmuch as people still use it anyway.) In particular, CMake is not distributed with Xcode. This means that engineers at Apple--who may I remind you all still drives the bulk of LLVM, Clang, and especially LLDB development, though IBM, Intel, AMD, and especially Google have really stepped up their contributions recently--and for whom you yourself, Eric, once worked until somewhat recently--won't be able to build their own shiny new toolchain at all, unless they can somehow convince management to install CMake. In fact I seem to recall quite recently someone from Apple (Jim Ingham?) on one of the LLVM lists complaining that he wanted to use ninja, but couldn't because he couldn't get ninja and CMake installed on his workstation. Until this changes--and good luck with that--expect heavy resistance from anyone still at Apple (other than Doug Gregor, of course :). - Some people around here don't like CMake very much, if at all--Daniel Dunbar, I'm looking at you! I've brought this up before, but I distinctly recall Daniel saying he had some kind of plan for making a new Python-based build system for LLVM. Those LLVMBuild files scattered throughout the tree? That was supposed to be the start of it. I don't know if he's abandoned those plans or what, but I think we should consider all our options before we commit to CMake. (Then again, Python isn't exactly everywhere either. It's more widely distributed than CMake--Mac OS X and damn near every Linux distro comes with it--but again, Windows doesn't come with it either. And I recall some other people raising objections to a Python build system because of that...) Heck, I'll admit that *I* don't like CMake that much, either. It's certainly better than "autohell" (as one person on this list put it), I'll give it that. But I think we can do better than CMake. Granted, CMake is the easiest alternative to autoconf, since we have most of the infrastructure for it in place already, but what will we do when sometime (5, 10 years?) down the line we find that CMake is inadequate and want to move off of it? This--the beginning of the next release cycle, as others have pointed out--is exactly the right time to consider alternative build systems so we can work the bugs out of them in time for 3.4. Now if you'll excuse me, I need to go put on a flame-retardant suit... Chip
> Can anyone see good a reason not to move to cmake as our only build > configuration system and drop future support for autoconf + makefiles > now that 3.3 has branched?I know of a small bug (pr14189) which breaks LTO and a bigger one: when building compiler-rt the host compiler is used. For these reasons I currently uses cmake for day to day development but have to use configure to build the clang as I use as my system compiler. If those issues are fixable, I would love to let autotools go. Cheers, Rafael
On Wed, May 22, 2013 at 04:14:06PM -0700, Eric Christopher 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 > that needs it can instead move to: > > build native clang > build next clang with some target that supplies a sysroot and a > -target option to the native clang > > Can anyone see good a reason not to move to cmake as our only build > configuration system and drop future support for autoconf + makefiles > now that 3.3 has branched? >I'm not sure if this is still the case, but at one point autoconf and CMake were generating shared objects differently. autoconf builds placed everything in one shared object, while cmake builds placed each component in its own shared library. I don't think this is something that would prevent LLVM from switching to CMake, but it is one potential trouble spot for users. -Tom
On Wed, May 22, 2013 at 8:33 PM, Charles Davis <cdavis5x at gmail.com> wrote:> > On May 22, 2013, at 5:14 PM, Eric Christopher wrote: > > > Hi All, > > > > Can anyone see good a reason not to move to cmake as our only build > > configuration system and drop future support for autoconf + makefiles > > now that 3.3 has branched? >+1.> - CMake is not available everywhere. Bourne shells are*. > > As I recall, this is the reason autoconf generates shell scripts: because > nearly every operating system out there comes with a shell! Even the > old-timey MPW development environment for the Mac came with one! (* Even > Windows comes with a shell, though it's not a Bourne shell but something > else entirely with a few constructs borrowed from the Bourne shell's > predecessor, the Thompson shell. But I only care about Windows inasmuch as > people still use it anyway.) >I just want to point out that that's a huge asterisk. In particular, CMake is not distributed with Xcode. This means that> engineers at Apple--who may I remind you all still drives the bulk of LLVM, > Clang, and especially LLDB development, though IBM, Intel, AMD, and > especially Google have really stepped up their contributions recently--and > for whom you yourself, Eric, once worked until somewhat recently--won't be > able to build their own shiny new toolchain at all, unless they can somehow > convince management to install CMake. In fact I seem to recall quite > recently someone from Apple (Jim Ingham?) on one of the LLVM lists > complaining that he wanted to use ninja, but couldn't because he couldn't > get ninja and CMake installed on his workstation. Until this changes--and > good luck with that--expect heavy resistance from anyone still at Apple > (other than Doug Gregor, of course :).Do you mean Jim Grosbach here? http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061330.html My take away was that switching to CMake is a large but superficial workflow change that takes time to get used to. w.r.t. the comments about ninja, LLVM doesn't need to push that as the preferred build system. 'make' works fine out of the box. ninja is just useful if you want faster builds and are willing to build your own binary. Here's an angle I haven't heard: CMake can generate XCode project files. I'm not sure that matters to anyone who works on LLVM, but it would make it easier for Apple to dogfood their own IDE. I also hear the generated project files are not so good, though. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130522/0b95a0c3/attachment.html>
Yes please. On the practical side, our internal CI does cmake/autoconf x debug/release x gcc/clang (on linux). Cutting out autoconf reduces the number of combinations per build from 8 to 4. This probably doesn't matter to most people but it would be great for us. paul On 2013-05-22 7:14 PM, "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 that's not supported in cmake. I'll send >out an assertion here that this support isn't necessary and any system >that needs it can instead move to: > >build native clang >build next clang with some target that supplies a sysroot and a >-target option to the native clang > >Can anyone see good a reason not to move to cmake as our only build >configuration system and drop future support for autoconf + makefiles >now that 3.3 has branched? > >-eric >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Paul, you can also just not test autoconf. Why does it matter to you if the autoconf files are there or not ? On May 22, 2013, at 8:30 PM, "Redmond, Paul" <paul.redmond at intel.com> wrote:> Yes please. > > On the practical side, our internal CI does cmake/autoconf x debug/release > x gcc/clang (on linux). Cutting out autoconf reduces the number of > combinations per build from 8 to 4. This probably doesn't matter to most > people but it would be great for us. > > paul > > On 2013-05-22 7:14 PM, "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 that's not supported in cmake. I'll send >> out an assertion here that this support isn't necessary and any system >> that needs it can instead move to: >> >> build native clang >> build next clang with some target that supplies a sysroot and a >> -target option to the native clang >> >> Can anyone see good a reason not to move to cmake as our only build >> configuration system and drop future support for autoconf + makefiles >> now that 3.3 has branched? >> >> -eric >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130522/9c3be19a/attachment.html>
On May 22, 2013, at 5:33 PM, Charles Davis <cdavis5x at gmail.com> wrote:> In particular, CMake is not distributed with Xcode. ... couldn't because he couldn't get ninja and CMake installed on his workstation.I'm not sure where you got the "cmake isn't included in xcode, therefore noone can use it on an apple platform". That is just utter nonsense. BTW, whoever cross posted this to three different lists, please do *not* do this. It makes moderation a huge PITA. -Chris
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 that's not supported in cmake. I'll send > out an assertion here that this support isn't necessary and any system > that needs it can instead move to: > > build native clang > build next clang with some target that supplies a sysroot and a > -target option to the native clang > > Can anyone see good a reason not to move to cmake as our only build > configuration system and drop future support for autoconf + makefiles > now that 3.3 has branched? >Hi Eric! Does cmake support in-tree builds yet? Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130522/142234d5/attachment.html>
On May 22, 2013, at 4:14 PM, Eric Christopher <echristo at gmail.com> wrote:> 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 > that needs it can instead move to: > > build native clang > build next clang with some target that supplies a sysroot and a > -target option to the native clangAren't there issues with tblgen needing to be compiled for the host even in the second round in this configuration? --Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130522/48f74692/attachment.html>
On Wed, May 22, 2013 at 11:27 PM, Nick Lewycky <nlewycky at google.com> wrote:> 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 that's not supported in cmake. I'll send >> out an assertion here that this support isn't necessary and any system >> that needs it can instead move to: >> >> build native clang >> build next clang with some target that supplies a sysroot and a >> -target option to the native clang >> >> Can anyone see good a reason not to move to cmake as our only build >> configuration system and drop future support for autoconf + makefiles >> now that 3.3 has branched? >> > > Hi Eric! Does cmake support in-tree builds yet? >I believe the only blocker for this is that the Makefiles from the autoconf build system are in the way, so we block in-tree CMake builds to avoid blatting them. Other than that it's fine, and (with the block removed) it already seems to work fine (for instance, with the ninja backend)... except that it litters your source area with extra files, and maybe you could look at this as an exciting opportunity to switch to a better workflow? ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130523/c825bcaa/attachment.html>
Hi Eric, On 23/05/13 01:14, Eric Christopher 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 > that needs it can instead move to: > > build native clang > build next clang with some target that supplies a sysroot and a > -target option to the native clang > > Can anyone see good a reason not to move to cmake as our only build > configuration system and drop future support for autoconf + makefiles > now that 3.3 has branched?I'm OK with moving to cmake only. However there are a bunch of bug reports in bugzilla about missing cmake features which should be resolved (eg: lack of support for expensive checks). Ciao, Duncan.
On 23 May 2013 00:14, Eric Christopher <echristo at gmail.com> wrote:> Can anyone see good a reason not to move to cmake as our only build > configuration system and drop future support for autoconf + makefiles > now that 3.3 has branched? >Hi Eric, The main issue I can see is that all buildbots currently use autoconf and changing it is not a simple matter of using CMake. It's embedded in the python library and might not be trivial to migrate. Also, the release test relies heavily on it, though this one would be easier to change, I think... What I think we should be asking ourselves first is: Shouldn't we migrate all uses of autoconf for CMake? Except for some rants and a few minor bugs that should be fixed anyway (if not by us, by CMake), I can't see a reason why not move to one build system. If that's going to be ready for 3.4, I don't know, and I wouldn't make an effort to deprecate autoconf on any future release *before* our main systems stopped depending on it. I currently use CMake+Ninja on native builds on both x86 and ARM without problems, but I agree that cross-compilation is not yet mastered. If we fix these, and move buildbots to CMake, I guess you'll be able to ask that same question again. Regarding the test-suite, I don't think we should move *all* LLVM projects to CMake at the same time. It would be great to have them all using CMake, and we can (should) strive to do that, but it's not necessary to migrate all or nothing, all at once. However, once we decided that we'll go with CMake, for the sake of simplicity, I think we should enforce that every LLVM (official) project uses CMake as well. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130523/ffba85b0/attachment.html>
Renato Golin <renato.golin at linaro.org> writes:> I currently use CMake+Ninja on native builds on both x86 and ARM without > problems, but I agree that cross-compilation is not yet mastered.What's wrong with cross-compilation?
On 23 May 2013 10:05, Renato Golin <renato.golin at linaro.org> wrote:> The main issue I can see is that all buildbots currently use autoconf and > changing it is not a simple matter of using CMake. It's embedded in the > python library and might not be trivial to migrate. Also, the release test > relies heavily on it, though this one would be easier to change, I think... >Created a bug for that: http://llvm.org/bugs/show_bug.cgi?id=16120 cheers, -renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130523/57dd67af/attachment.html>
On Wed, May 22, 2013 at 04:14:06PM -0700, Eric Christopher wrote:> Can anyone see good a reason not to move to cmake as our only build > configuration system and drop future support for autoconf + makefiles > now that 3.3 has branched?I don't really care about the Makefiles, but dropping configure makes integrating it into NetBSD a lot harder as it would force the cmake dependency into the toolchain dependencies. Joerg
On 23 May 2013, at 07:53, Owen Anderson <resistor at mac.com> wrote:>> build native clang >> build next clang with some target that supplies a sysroot and a >> -target option to the native clang > > Aren't there issues with tblgen needing to be compiled for the host even in the second round in this configuration?I am currently using the CMake build system to cross-build LLVM/Clang for MIPS. I have two build directories, one which builds for x86 and one for MIPS. The MIPS build directory is set up to use the compiler and tablegen from the host. There are a few minor issues, but nothing serious. Having to specify the location of llvm and clang TableGen separately seems redundant. It would be nice to just say 'here is my existing LLVM/Clang build directory, use everything from there (including the compiler)'. The more annoying problem is that for some reason, the LLVM CMake files don't respect CMake toolchain files - I didn't even think this was possible - so I need to manually specify all of the things that are specified in the toolchain file. I don't understand the compiler-rt issue. It can't be built with the just-built clang because that clang won't run on the build system. It has to build with the cross compiler. David
On 23 May 2013, at 13:51, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:> I got a CMake warning telling me that the variable for specifying the toolchain file was unused when I set it on the command line, and none of the variables were propagated. It's been about a month since I tried though, so it may have been fixed.I get that warning, but it works anyway. Some of the options are forwarded (CMAKE_CXX_COMPILER being particularly important) others just disappear (presumably having done their job).>> Do you also see the "make -j9 dies" issue? > > I use ninja -j64 and it works fine.Hmm. There must be something odd in my setup. I wonder if the two are linked in some bizarre way… Tim.
On May 22, 2013, at 4:14 PM, 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 that's not supported in cmake. I'll send > out an assertion here that this support isn't necessary and any system > that needs it can instead move to: > > build native clang > build next clang with some target that supplies a sysroot and a > -target option to the native clang > > Can anyone see good a reason not to move to cmake as our only build > configuration system and drop future support for autoconf + makefiles > now that 3.3 has branched?Apple needs to continue supporting various cross-builds, and while I believe you that it could be done as you suggest, it would take a bit of work to get it right for all the different ways we build clang and llvm. I haven't seen the maintenance of configure+make to be a significant burden. Yes, it's kind of gross to have two build systems, and it can be annoying to keep them both working, but I would much rather keep the configure+make system working so that we can invest our efforts in actually making llvm a better compiler.
On Fri, May 24, 2013 at 10:28 AM, Bob Wilson <bob.wilson at apple.com> wrote:> > On May 22, 2013, at 4:14 PM, 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 that's not supported in cmake. I'll send >> out an assertion here that this support isn't necessary and any system >> that needs it can instead move to: >> >> build native clang >> build next clang with some target that supplies a sysroot and a >> -target option to the native clang >> >> Can anyone see good a reason not to move to cmake as our only build >> configuration system and drop future support for autoconf + makefiles >> now that 3.3 has branched? > > Apple needs to continue supporting various cross-builds, and while I believe you that it could be done as you suggest, it would take a bit of work to get it right for all the different ways we build clang and llvm. I haven't seen the maintenance of configure+make to be a significant burden. Yes, it's kind of gross to have two build systems, and it can be annoying to keep them both working, but I would much rather keep the configure+make system working so that we can invest our efforts in actually making llvm a better compiler.This is a pretty fair point and a lot of other good points have been made on the thread, however, let me respond to this one in particular with a sort of summary of where I'm coming from since, as I understand it, I may have caused a bit of excitement which is unfortunate because I sent this rather off the cuff based on a lunch conversation to get some discussion started: a) the larger problem is adding new functionality to the compiler, we can see this in libc++ and compiler-rt in particular in that they use their own custom makefile system in order to build their libraries. Not integrating with the project as a whole. There are aspects of the system that don't work with cmake, and aspects that don't work with autoconf/make. Pretty ugly. b) It's definitely twice the work to add anything to the system. This is pretty frustrating and people familiar with one system or the other usually end up asking someone familiar with the other system to add the support they're looking to add. c) Yes, moving to a single system is definitely a bit of work. I sent this out mostly as a "hey, let's see what's going on here since I'm pretty sure few people think that having two build systems is a good idea and cmake seems to cover the most cases". Part of the reason of sending this out is an attempt to see what really is necessary to have the whole thing (compiler, debugger, libraries, etc) build with one system on as many hosts as possible with as much flexibility as we can manage. d) The timing: The timing of this message was due to 3.3 having branched and the release cycle starting. I fully expect any effort to move to a single build system across all of llvm to take the majority of a release cycle with just volunteer time. This I figure gives the most people the most time in order to deal with any internal fallout that their various build systems need to handle and to come up with any more blockers before we could remove any support for alternate systems (including autoconf/make). e) Is this possible at all? We've heard a lot on this thread of various problems, in particular, with cross builds. The cross building infrastructure in llvm right now is a little hacky, but it works. I think that Richard and I worked out a couple of ideas on how to get it going with cmake, but I'm anything but a cmake expert. I do want to reiterate that this is definitely a requirement before we could move forward. f) The point of the thread then... the point of this was to get a bunch of ideas of blockers to moving to a single build system. Two is pretty inconvenient (though I know we're not getting much pity from the Firefox, Safari, or Chrome people) and it's nice and clean if we can have one. -eric g) One last addendum - IMO yes, cmake is horrible. It's just hopefully _less_ horrible than the alternatives.