Add CMake build infrastructure #182

Merged
merged 2 commits into from May 22, 2012

Projects

None yet

3 participants

@jonforums
Contributor

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 matz merged commit 618697c into mruby:master May 22, 2012
@matz
Member
matz commented May 22, 2012

How can I make issue label?

@matz
Member
matz commented May 22, 2012

I have just found out. Done.

@matz
Member
matz commented May 22, 2012

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
Contributor

:(

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
Contributor

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
Contributor

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
Contributor

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.

@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
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment