Ray Tracing in pure CMake

> * 256x256: 226.28s, 15x compared to 64x64.

Basic ray tracers compute one ray for each pixel (without reflection/refraction), so that this increase in time is expected, as it's roughly 256²/64²=4². This is also due to the fact that each ray is independently computed.

I don't know if sophisticated ones can save some (rays) computation by interpolating.

There seems to be a kind of “network effect” here with CMake, considering how popular it is among C/C++ projects.

Meson is more or less equivalent in the functionality it provides. There is also Gradle, but it doesn’t seem to have gained much traction outside of Android development.

My personal favorite is Bazel (and others from the Blaze family of build systems). It uses a python-based language for describing build rules, an extensive documentation and developers that respond to issues. Among the downsides is the lack of proper dependency management which is critical for public, open source projects.

There is also Nix which takes it even further, but it requires much more involvement from the developer.

Everyone's experience is different, but that's very different from my memory of autotools - a Turing-complete macro processor which generates several thousand lines of pre-modern shell script with embedded C source codes. When anything goes wrong, it's pretty much impossible to match it to the original macro definition. Just so that one can hypothetically build the project in an ancient UNIX system which is so old that its shell doesn't even have functions.

I still don't understand why cmake/autotools are seriously considered. If you have a tool that is hard to do complex things with (i.e., complex Makefile operations), the solution should _not_ be a tool to generate input for that tool (i.e., CMake/autotools generating makefiles). We shouldn't use a build system whose artifacts are scripts in a cruftier build system; we should replace the universal build system whole-cloth. Even the portability argument fails: if any modifications to the build system require installing the respective meta-tool (cmake/autotools), the generated Makefile is nearly-useless for anyone trying to modify that codebase in any substantial way. We need tools that do the actual building, not Makefile meta-languages.

Well, first let me say that I agree that neither cmake nor autotools is perfect.

I am saying that cmake is fundamentally broken and unfit for purpose even in addition to what you mention. I've mentioned some in another comment here, but really why cmake should be thrown in the garbage is too long a rant to fit into a comment field.

I am VERY interested in hearing new ideas. If you have a truly better way, then I want to use it.

Though I'm not sure why you say generating code is so bad. Code gets compiled to machine language, and (especially with optimizations and all the new fancy instructions) are not a thing that most people usually look at anymore.

Yes, actual developers need automake/autoconf installed. Of a sufficiently recent version. But what exactly is your suggestion? Autotools at least makes this an issue only for the developers (and not even all of them, since they may not need to change things), not for the orders of magnitude more users.

But this is not a unique thing to developers. There may be other generated code. E.g. they need to have protobuf compiler installed, with all the plugins required. End users, even those who build, don't. Developers who don't modify those parts don't.

But here's the main thing though: Any portable build system, that already requires EVERY user to have that build system installed, is DoA for being a viable portable build system.

It's incredibly frustrating to download a package, only to find that the build system the author in their infinite wisdom chose to use, has not been ported to your platform (or if it has, you have to yak shave for a few hours to get it and its dependencies installed). So you can't compile the thing.

The beauty of autotools is that it "compiles" to a "virtual machine" (shell) that will truly run anywhere. Nowadays even on Windows, which now ships bash.

CMake too fails on this aspect, in addition to all the other aspects this box won't be able to fit.

But please, I truly mean that if you have a better way, then I do want it. It's incredibly hard to build something portable though. Hence the minimal dependency of "just a POSIX shell" for autotools.