Add an option to build with CMake

[mkoloberdin]

This set of patches adds an option to build the project with CMake in addition to autotools. Tested on Linux and macOS and also cross-compilation for win32/64 from Linux. Visual Studio project generation (see README) should also work but needs testing.

[dodona2]

great!

[rofl0r]

yet another cmake takeover? i dont get why cmake fans are so keen on getting that crap spread, and how you can even become a fan of it in the first place. :-1:

[dodona2]

because its smarter and cleaner than the outdated autoxxx package.

[rofl0r]

smart? no way. there's a reason it's listed on suckless' sucks page: https://suckless.org/sucks/

[mkoloberdin]

@rofl0r According to that page this whole project sucks big time as it is written in C++ rather than C. And isn't it ironic that you talk of fanaticism and then refer to a page based on nothing but "C/GNU/Make etc." fanaticism? (guess what, C sucks big time too: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html ) We live in an imperfect world, it can be indeed argued that CMake is a pile of crap too but as opposed to what? CMake solves some problems pretty well, such as more or less uniform specification of build rules CROSS PLATFORM. It's about practicality not fanaticism.

[mkoloberdin]

I must say though that I do enjoy (and somewhat share the sentiment) of grumpy writings such as suckless. Here is a lot more deep one on a related subject: http://www.loper-os.org/?p=69

[rofl0r]

actually, C++ should just die. so when the author of this program didnt show up for some years, i already prepared a fork with the purpose of de-C++-ifying it as i have done with visualboy advance, for example https://github.com/x3ro/VisualBoyAdvance/pull/4 .

as i happen to be the author of sabotage linux, back in 2011 when musl libc was quite new (and didnt support C++ yet), i had major issues with the (at that time) 2 projects i needed that uses cmake, openal and libssh. since there was no way how i could bootstrap cmake (due to being written in C++), i had to rewrite the Makefiles for both projects in order to be able to use them (first i tried to get cmake to produce standalone makefiles, but no dice). once C++ was supported in musl libc, the trouble with cmake wasnt over though. when i tried to build my distro in qemu for other archs, building cmake would either fail due to out-of-memory being such a behemoth, or when the system emulated by qemu happened to have enough RAM, it would take like 8 hours to build (taking about 3x the time of GCC). that's just inacceptable. look at gnu make, it builds in like 5 secs on a normal PC, and maybe 2 minutes in qemu.

[mkoloberdin]

@rofl0r I recall stumbling upon your website and reading that "sucks" page and your philosophy page. I agree with many of your concerns but I find it surprising that you apparently think that rewriting everything in C (roughly speaking) can somehow reduce complexity. Let me quote from your "philosophy" page:

Code complexity is the mother of bloated, hard to use, and totally inconsistent software. With complex code, problems are solved in suboptimal ways, valuable resources are endlessly tied up, performance slows to a halt, and vulnerabilities become a commonplace.

THE most valuable and scarce resource involved in the process of software development is human brain (a bit advanced monkey brain, no matter how intelligent you are). Polluting it with copious low-level abstractions (the only kind C is capable of) is antithetical to managing complexity. Even the dreaded C++ can help to somewhat alleviate this problem when used right. (see books by Alexander Stepanov for instance) C++'s problem is that it allows for easy generation of bloat, not that it's inherently "bloat-generating." Rust takes it a bit further (marginally). Strictly-typed pure functional languages such as Haskell and Idris take it to the whole new level (Idris especially, although unlike Haskell it is not entirely production-ready yet), plus they radically restrict your ability to create bloated mess which is easy to do in C++ or undefined behavior or memory allocation minefield which is easy to do in C. Bloat can be reduced orders of magnitude thanks to higher level abstractions and isolation of global mutation. ("side-effects") Seriously, do yourself a favor, if you are serious about your goals, read / work through this free book: https://softwarefoundations.cis.upenn.edu/

This same approach also allows for better management of lesser valuable (yet valuable) resources such as CPU ticks and RAM, although Haskell is not always on par with C code in terms of performance (yet... linear types will help with that: http://blog.tweag.io/posts/2017-03-13-linear-types.html )

Here is another illustration of what can be achieved using this approach: http://www.impredicative.com/ur/

The Ur/Web compiler also produces very efficient object code that does not use garbage collection. These compiled programs will often be even more efficient than what most programmers would bother to write in C. For example, the standalone web server generated for the demo uses less RAM than the bash shell.

(the author of this language also wrote this book: https://www.amazon.com/Certified-Programming-Dependent-Types-Introduction/dp/0262026651/ )

Read that "Software Foundations" book! Thank me later ;) And your love of low-level code/optimizations would not be lost in that world either. Compilers always need improving.

[mkoloberdin]

Visual Studio project generation (see README) should also work but needs testing.

Tested with VS 2013 today: it works.

[mkoloberdin]

"Platform Toolset" can be specified on command line (e.g. to achieve WinXP compatibility as in 7e05618) as such:

cmake -G"Visual Studio 12 2013" -T v130_xp ..

Perhaps this should be mentioned in the README.

[rofl0r]

thanks for your booktip. now i'd like to share a video lecture tip for you, since you seem to believe into that monkey brain stuff: https://www.youtube.com/watch?v=dmaLP38GhlU - enjoy!