Add CMake build infrastructure

[jonforums]

After committing, please add a "cmake" issues label (from the GH gui) for tracking cmake specific build problems.

If master moves forward before this pull request can be merged without conflicts, let me know and I'll rebase and rewrite this branch to that you can easily merge from the GH gui without conflicts.

[matz]

How can I make issue label?

[matz]

I have just found out. Done.

[matz]

Unfortunately minimum required version (2.8.8) is too high for me to try.
I have 2.8.7 installed (from Ubuntu 12.04).

[jonforums]

:(

I use a new 2.8.8 feature to cleanly build non-archived objects (similar in function to lib/libmruby_core.a) and re-use.

"[2.8.8]...added a new OBJECT_LIBRARY target type to provide CMake-flavored convenience libraries."

Can you easily use the 32bit Linux binary download from cmake.org since neither precise nor precise-backports yet contains 2.8.8?

http://cmake.org/cmake/resources/software.html

[jonforums]

Since quantal has 2.8.8 in its repo http://packages.ubuntu.com/quantal/devel/cmake you can add the quantal repo to your /etc//apt/sources.list file and hope cmake 2.8.8 is OK with existing precise deps.

But this can be a problem since the pkg mgr will show that other precise pkgs can be upgraded to quantal. My guess is that you don't want to such an edgy mixed system.

I don't know how to restrict apt to only "seeing" cmake 2.8.8 from the quantal repo. I think you can do it with "apt-pinning". I'll be back with info if I figure out an easy way for you to pull in only cmake 2.8.8 from quantal.

[dmacvicar]

For development it is ok and easy to get 2.8.8, but any Linux distribution package that wants to build using cmake will have pain with the version requirement.

[jonforums]

I don't like the APT-pinning idea because it adds too much complexity.

Given that both Arch and MacPorts already have 2.8.8 in their repos, and cmake.org has a 32bit Linux binary download, I'm going to add a note to CMake Compatible briefly describing how to install the binary into /usr/local or /opt or ~/cmake and update PATH.

I think it's a much less tweaky solution than apt-pinning.

@dmacvicar if you've got a 64bit Linux, would you confirm that the official CMake 32bit Linux binary works and is an usable?

[jonforums]

Bottom line: I want Matz to be able to use CMake as his primary build tool and I will change the CMake stuff to support 2.8.7 if that's what he requests.

[jonforums]

Wiki doco updated https://github.com/mruby/mruby/wiki/CMake-Compatible

[dmacvicar]

@jonforums I can confirm that on 64 bits the official 32-bit cmake binary builds. I tested irb and it is usable.

About the cmake version, Fedora has 2.8.7 in the update channel. openSUSE has 2.8.6.

[jonforums]

@dmacvicar thanks for verifying and checking other distributions!

While not ideal, I'm going to address the CMake versioning concerns with wiki documentation. If it turns out to be a bad decision and we get too many new issues, I'll refactor the CMake code.

I've started a new wiki page describing how to build mruby https://github.com/mruby/mruby/wiki/Building-mruby As time permits, I'll add details.

Since it's a (versioned) wiki page, everyone should feel comfortable tweaking it until it's great.