[LLVMdev] Is there room for another build system?

Alain Frisch alain.frisch at lexifi.com
Thu Jul 31 00:05:10 PDT 2008


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

As a potential user of LLVM, I'm very happy to see some activity around 
the build system. If my company goes the LLVM route, we will want good 
support for building LLVM from the command-line both on Windows (MSVC + 
MinGW) and on Linux. I'm a little bit concerned by the fact that VS 
projects will be the only way to build LLVM with MSVC. Will the 
CMake-based approach support generating makefiles for MSVC builds?

I also have some concerns on the approach followed by CMake, but I've 
never tried it, so I might be completely wrong. The first concern is 
that generating makefiles, solutions, projects forces the build system 
to inherit the limitations of the supported underlying build tools; for 
instance, generated makefiles will still use timestamps to trigger 
recompilations, instead of digests on the content (which is much more 
robust and can avoid a lot of useless recompilations). Another typical 
limitation of make is the way dependencies are computed. With CMake, are 
dependencies computed when makefiles are generated, or by makefiles 
themselves? In both case, I guess the developer needs to perform some 
explicit action when dependencies changes, otherwise things might work 
well on his current tree but fail in a clean checkout.

Also, if Makefiles are to be generated for Windows, things like 
supporting pathnames properly and escaping is really tricky (or does 
CMake do a perfect job here?). Since most developpers won't be able to 
test their changes to the build system on all platforms, I expect the 
system to be broken quite often.

An approach like scons, which does not rely on legacy tools, seems more 
robust to me. At least we can expect a similar behavior of the build 
system on all the supported platforms. I haven't tried scons itself, but 
my company is happily using the OMake build system

http://omake.metaprl.org/index.html

OMake has binary packages for several architecture and it does not 
depend on external tools. It comes with a cross-platform and high-level 
shell built-in. Automatic dependencies are computed dynamically, and 
recompilation is triggered by digests, not timestamps. We build our 
entire system on Windows (both with MSVC and MinGW) and on Linux, and we 
are very happy with it. If anyone is interested to evalute whether OMake 
would be a good solution for LLVM, I'm willing to provide help and some 
resources (although I won't be able to do the whole thing myself).


-- Alain



More information about the llvm-dev mailing list