Add CMake build option and include it in the readme

[rikvdh]

Some people probably want to use CMake to include termbox in their project. Waf is also not used a lot throughout the C/C++ community, but I'm leaving that as is.

[nsf]

Yes, I understand that cmake is nice and all that, but I don't want to make a build system zoo in the repo. My suggestion for people who use termbox is to just include the lib into their project. The lib requires almost no configuration. So, I'm not sure I want to accept this pull request, but let me think about it, I'll decide what to do in few days.

[Lukc]

Yes, termbox is completely trivial to integrate into another project, or even to build standalone. I see no reason at all to add support for another build system.

Besides, CMake is known to be confusing (does not regenerate if you add new flags unless you explicitly remove its cache, confusing parameters, confusing cross-builds, …). I know I’m coming out of nowhere and that my opinion has little value here, but I’m definitely against CMake support. :)

[xor-gate]

@Lukc it seems you don't really have used CMake in serious software projects. Those arguments are the complete opposite of what CMake provides and is possible due to ignorance.

Sure don't integrate it at all. Stick with the homebrewed build systems, or keep yourself stuck in the '70s with make and autotools.

[Lukc]

Sure. Because we need complex build systems to build or maintain termbox. There is little if anything to gain.

Or, maybe you’re in favor of the “build system zoo” that nsf described? In which case I have nothing to argue against.

(as a side note, yes, being in favor of keeping waf means I’m ignorant of what CMake does and that I support the autotools :) )

[rikvdh]

I shouldn't say CMake is complex. Have you ever tried maintaining autotools? CMake is like a very big toolbox. All build systems aren't designed to change some rules and then recompile. The idea is that rules can stay the same for ages.

CMake is also very cross-platform and has found its way into various IDE's e.g. CLion, Visual Studio. Also with CPack you can easily generate packages for various distros (APT, RPM, etc.). See https://cmake.org/Wiki/CMake:CPackPackageGenerators. Integration with unit-testing via CTest is also a nice addition. Integration of Dynamic analysis and code-coverage are very clean.

I can understand that a zoo is not what we're aiming for, but removing Waf in the same commit felt a bit destructive. If I maintained the project I went for CMake and deprecated Waf, and removed it after the next major release.

Having a build system which is cross-platform without the direct need of Python is a benefit on its own. But every developer has its own opinion on this topic, it is to @nsf to decide.

I'm having all kinds of ideas for Termbox, but having a build system which is more widely accepted in favor to Waf is step 1 for me.

[nsf]

Well, the termbox has a big history with build scripts. I used a bash script in past, but then somebody contributed makefile and them somebody contributed a cmake file and it was a zoo. Then I decided to wipe it all out and move it to waf because I was using waf at the moment everywhere else. But since then Qt Creator was released, which had only two options for build scripts: qmake or cmake, so I really liked IDE for C++ project and it made me switch from waf to cmake everywhere. Technically I use cmake for all my C/C++ projects now, but I just don't want to break existing package builds (I know some distros have termbox packages). So, perhaps, how about this. We switch to cmake, but to do so we need to introduce some major feature, for example a winapi port. It's one of the forever TODO features in this project. Because frankly, I just prefer using termbox-go (Go version of the termbox, maintained by me as well).

So, there, I will move to cmake when termbox gets windows OS port. Be it by me or if somebody contributes. It's an easy task to acomplish, because there is a termbox-go windows port and you just need to port the code, however one complicated part is the main loop. In termbox-go mainloop is modeled with language built-in tools such as channels/goroutines and select statement. With C it's always a tough choice, I think I had a TODO in code somewhere where I say it would be nice to integrate with third party main loops, such as glib for example. Event driven programs are still as painful as fuck in C. Or maybe some libuv integration as well, dunno, nodejs people will be happy with that option.

So there, together with some major changes to termbox I'm okay to move to cmake. The sad part is that I have no time and frankly desire to work on that.

[rikvdh]

Good response @nsf! Windows support is something my application can benefit from as well. I'll try to fix that shortly.

Porting from the Go-port seems the most easy path.

[rofl0r]

cmake is mentioned here http://suckless.org/sucks/
i suspect a good build system could be written in less than 2000 lines of code, however cmake is at the opposite end of the scala. measured by the time it takes to build and space on my hard drive, it's more complex than GCC C compiler + GCC C++ compiler + libgcc runtime libraries + libstdc++ which are all built during the there mentioned GCC compile.
really the only point that speaks for cmake is that it works for windows (with a gui for the clicky-click windows folks).

[edg-l]

Actually cmake is nice and you should support it.

[luciusmagn]

cmake is very bloated, no. That doesn't prevent anyone for making own forks that use all those bloated build systems and whatnot, though.

[xor-gate]

@rikvdh just close it, people still living in caves

[rikvdh]

I don't thing CMake shall be integrated any time soon.