[LLVMdev] Is there room for another build system?
Chris Lattner
clattner at apple.com
Wed Jul 30 10:43:14 PDT 2008
On Jul 30, 2008, at 9:41 AM, Óscar Fuentes wrote:
> I'm evaluating CMake (1) primarily as an alternative build system for
> Visual Studio users, although it can easily be a replacement for
> `configure' and hand-made makefiles too, providing a single build
> system
> for all platforms. CMake is a tool that takes a project description
> and
> configures, generates makefiles, project files for IDEs, etc as
> requested.
Ok. Killing off autoconf would be a huge bonus, but should probably
be done as a second step.
> There are three MS C++ compilers capable of compiling LLVM: Visual
> Studio 2003, 2005, 2008 and their respective "free tools"
> edition. However, the project files distributed with LLVM are for
> 2005. This means that people using 2003 is left in the cold and people
> who only have 2008 must convert the project files and, most important,
> can't contribute to the maintenance of the VC++ build.
Yes, this is a problem. We also support Xcode to various degrees on
the mac, and keeping all these project files in sync with the
makefiles is a pain.
> Furthermore, CMake can replace `configure' and generate gmake
> makefiles,
> project files for XCode, etc.
Having one point of truth would be great.
> Now, my questions:
>
> 1. General LLVM users: Are you so happy with `configure' and hand-made
> makefiles that you wont consider an alternative? If you are
> interested,
> I can steer my work to cover all platforms.
I would prefer to kill off makefiles if we have something better. We
really only want to support one build system.
> 3. LLVM administrators: Do you object to having a CMakeLists.txt file
> on every source directory?
No, particularly if it means we eventually lose the Makefile :).
One trick is that we want to keep llvm-config and the
'LINK_COMPONENTS' system used when building tools. I am sure cmake
can handle this, but I just wanted to mention that it is important.
-Chris
More information about the llvm-dev
mailing list