State of CMake build system.

IMHO, the CMake-based build system is almost complete enough to replace
current MSVC++ project files (modulo some community review and
bug-fixing). Is this enough for adding it to the LLVM repo?

From the point of view of a MSVC++ user, the new build system is trivial

to maintain: you can add a new library or tool executable in less time
that it takes to open the project file on MSVC++, it covers VC++ 2003,
2005 and 2008, generating project files or NMake makefiles on demand and
it just requires a text editor for maintenance. It is on my TODO list to
add a mode that doesn't require an explicit list of source files, just
as LLVM make-based build system does now. IMHO it is a clear improvement
over what MSVC++ users have now, with the requirement of CMake as the
only drawback. However, CMake is trivial to install on Windows.

It works for MinGW and Linux too, but it far from complete. Only
supports the X86 target (although adding targets is not hard) and lacks
lots of bells and whistles that ./configure && make have now. More
specifically, it lacks all options configure has. I'm pretty confident
that, with not too much work, the CMake build can catch up with
./configure && make and improve over it. Mostly on the maintenance
area. The amount of explicit "bussiness logic" CMake demands is orders
of magnitude smaller than ./configure && make. CMake has its rough
edges, though, and there are things that I don't like, but it saves lots
of work.

Finally, please note that the CMake build system is absolutely
unobtrusive wrt current build systems, either the make-based or the
MSVC++ project files, and I'm not advocating the deprecation of neither
of them.

Notes:

* MSVC++ users: there is no LLVMX86.o. Link against LLVMX86.lib and add
  /INCLUDE:_X86TargetMachineModule to your executable's link option.

* Right now it ignores most of the examples (only builds Fibonacci). As
  an exercise, you can add the CMakeLists.txt file to each example
  directory and make the needed modifications to examples/CMakeLists.txt.

* Has no make install nor test.

* It is more than likely that there are some missing dependencies and
  that parallel builds are not right (please check if you have time).

* Only out-of-source builds are tested.

* It seems that MSVC++ 2003 and 2008 builds fails due to C++
  issues. Patches highly welcomed.

* For MSVC++, only NMake builds are tested. Please test IDE builds.

* On non-MSVC++ targets, make VERBOSE=1 is very useful. Please attach
  the output of this command when reporting issues.

* I'm sure I'm missing some notes.

cmake.patch (71.9 KB)

This is an updated version of the patch that fixes some issues on VC++
builds.

cmake.patch (71.9 KB)

IMHO, the CMake-based build system is almost complete enough to replace
current MSVC++ project files (modulo some community review and
bug-fixing). Is this enough for adding it to the LLVM repo?

Yes.

From the point of view of a MSVC++ user, the new build system is trivial

to maintain: you can add a new library or tool executable in less time
that it takes to open the project file on MSVC++, it covers VC++ 2003,
2005 and 2008, generating project files or NMake makefiles on demand and
it just requires a text editor for maintenance.

This sounds great. I think the right approach is to check it in, and then give the people with a stake in windows development a chance to try it out. Assuming it works well (i.e., it is an improvement over the existing project files), we can then nuke the windows project files. Eventually, it would be great to keep extending it to support development on every platform, maybe we can kill off the xcode project files and even the makefiles someday.

Thanks for working on this Óscar!

-Chris

CMake for some other things as well.

shap

"Jonathan S. Shapiro" <shap@eros-os.com> writes:

Hi, FYI

I just tried this (from r56534). I get an "error" (below) from cmake
(2.6.1) about Intrinsics.gen but it seems to write out sln/vcproj
anyway.

Project.sln opens and builds OK (modulo a build error in llvmc2 that
looks build-system agnostic). Nice work!

Also, I get around 10k lines of warnings (not that that's different
than previously). Would it be desirable to silence those on VS builds
given that it might be easier now since the solutions are generated?
My suggested list would be: 4146, 4503, 4996, 4800, 4244, 4624, 4355,
4715 if there's somewhere easy to paste that. I think those are
unlikely to be interesting assuming the main development on OSX/Linux
is catching genuine problems, and would help reduce noise a lot.
There's a handful of others, but I'm not especially confident that
they're harmless.

scott

Hello Scott.

"Scott Graham" <scott.llvm@h4ck3r.net> writes:

I just tried this (from r56534). I get an "error" (below) from cmake
(2.6.1) about Intrinsics.gen but it seems to write out sln/vcproj
anyway.

That should be fixed now.

Project.sln opens and builds OK (modulo a build error in llvmc2 that
looks build-system agnostic). Nice work!

The failure on llvmc2 is, possibly, due to a missing file name on its
CMakeLists.txt. This has been corrected as well. Last time I checked the
MSVC++ 2005 build there was some VC-specific C++ error on a tool. I
don't know if this was corrected.

Anyways, right now the build is broken on all platforms due to an error
that, most likely, was allowed to pass the developer's checks by a bug
on the make-based build system. CMake catched the problem on the spot
:slight_smile:

Also, I get around 10k lines of warnings (not that that's different
than previously). Would it be desirable to silence those on VS builds
given that it might be easier now since the solutions are generated?
My suggested list would be: 4146, 4503, 4996, 4800, 4244, 4624, 4355,
4715 if there's somewhere easy to paste that. I think those are
unlikely to be interesting assuming the main development on OSX/Linux
is catching genuine problems, and would help reduce noise a lot.
There's a handful of others, but I'm not especially confident that
they're harmless.

Until very recently, I used /w (ignore all warnings) on the VC++
build. Strictly speaking, warnings should be fixed on the source code,
not just moved under the carpet, but I agree with you: this attitude
seems not realistic for the VC++ LLVM users, so I'll silence the
warnings you list.

OTOH, it seems to me that the development LLVM is too gcc-centric,
diagnostics from other compilers should be looked with special
attention, so we should take care on not shutting down interesting
warnings.

Thank you!