On 26 Jun 2012, at 20:26, James K. Lowden wrote:> I used autoconf to build Clang not because I'm "stuck" on a > system without Cmake, but because I have expertise in autoconf and none > with Cmake. I've never found Cmake compelling enough to justify > learning a new feature-test and dependency syntax.Before discussing the technical merits of CMake vs autoconf, we need to answer the question: Is having my favourite build system available a good enough reason to impose the maintenance burden of *two* build systems on the rest of the llvm & clang community? As a *user* of the build systems (i.e. only using them to compile, not actually editing the Makefiles/CMakeLists.txt) I already found it very confusing having two build systems. There is no documentation (except buried in the mailing lists) as to which projects / features / architectures are supported by which build system. And having two separate build systems almost guarantees that there will always be something that can only be built with one system or the other. That was as a user. I can only imagine how demoralising it must feel to have to add a new project or feature to two different build systems. 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 It seems to me from this thread† that the community has agreed that, once the CMake build system supports every project/architecture/etc that the autoconf build system can, the CMake system will become the official build system. It also seems clear from Doug's list‡ that the CMake system isn't ready yet. Is it really true that the CMake system doesn't run the LLVM test suite, or am I misreading Doug? I hate to think of the person-hours that have been spent on this discussion over the years, so it would be nice to achieve *something* from this round of the discussion. I propose that this decision be clearly documented: The long term goal is to support only the CMake build system; until then, new projects must support the CMake build system. I'm not sure where best to document it, though. So far I have found: * "LLVMBuild Documentation" at "Development Process Documentation" (http://llvm.org/docs/development_process.html) * "The LLVM Getting Started Guide" and "LLVM CMake guide" at "User Guides" (http://llvm.org/docs/userguides.html) * "Getting Started: Building and Running Clang" (http://clang.llvm.org/get_started.html) † Quotes from this thread:> I consider it a worthy goal.Douglas Gregor, On 21 Jun 2012, at 18:21> I'd rather we just pick cmakeChandler Carruth, On 21 Jun 2012, at 01:19 ‡ From Douglas Gregor, On 21 Jun 2012, at 18:21:> 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
>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 Jun 2012, at 01:19Unfortunately, when CMake is not even capable of one of the most fundamental tasks that anyone would care to use LLVM for, namely setting up project files to build LLVM as a DLL so they can build a compiler atop it, it can hardly be said to support all use cases!
On 27 Jun 2012, at 13:29, 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 autoconf+make can't support >> -- Chandler Carruth, On 21 Jun 2012, at 01:19 > > Unfortunately, > when CMake is not even capable of one of the most fundamental tasks > that anyone would care to use LLVM for, namely setting up project files > to build LLVM as a DLL so they can build a compiler atop it, it can > hardly be said to support all use cases!When you say "CMake" do you mean that *LLVM's CMake-based build system* cannot build LLVM as a DLL, or that *CMake the tool* has inherent limitations that prevent us from adding that functionality to the build system? If you mean the former, then let's add this to the list. Whichever you meant, thank you for the feedback. This is exactly the kind of thing we need to know. --Dave.
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 autoconf+make can't support >>-- Chandler Carruth, On 21 Jun 2012, at 01:19 > > Unfortunately, > when CMake is not even capable of one of the most fundamental tasks > that anyone would care to use LLVM for, namely setting up project files > to build LLVM as a DLL so they can build a compiler atop it, it can > hardly be said to support all use cases!What if you pass the command line option -DBUILD_SHARED_LIBS to cmake? For me that builds shared libs, and the description says it does too. stephen at hal:~/dev/src/llvm/build{master}$ cmake -i .. Would you like to see advanced options? [No]: Please wait while cmake processes CMakeLists.txt files.... Variable Name: BUG_REPORT_URL Description: Default URL where bug reports are to be submitted. Current Value: http://llvm.org/bugs/ New Value (Enter to keep current value): Variable Name: BUILD_SHARED_LIBS Description: Build all libraries as shared libraries instead of static Current Value: OFF New Value (Enter to keep current value):
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, > when CMake is not even capable of one of the most fundamental tasks > that anyone would care to use LLVM for, namely setting up project files > to build LLVM as a DLL so they can build a compiler atop it,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 MinGW. That hack can be easily replicated on CMake. As for Visual Studio, autoconf is pretty useless, so no dll's there in any case until someone sprinkles the LLVM C++ sources with the necessary declarations.> it can hardly be said to support all use cases!