Live data from Hacker News

Ray Tracing in pure CMake

64.github.io

111–120 of 167 posts

Re: Ray Tracing in pure CMake

#111
post #83

Earlier quoted context omitted.

While I've not had that problem, I can see that it's nonobvious. But it's years between me looking at the actual compiled output. I look at assembly output more often, and most people never even do that. What I mean though is that ./configure outputs a config.log that says exactly what was done. Exactly what command line was run and exactly what the error was. I guess I'm confused why you're even looking at the compi…

I just spent some time searching for m4 opinions on HN and it's more like a love-hate than hate-hate. It looks like if you dive head first into learning autotools, then m4 is going to look like nuisance. But if you allocate time to learn m4 for what it is, instead of just something you have to put up with as part of your autotools adventure, then you'll hate m4. m4 is the only (or one of a very few) well-known genera…

I don't hate m4. Could be worse, could be better.

I used to build websites using m4 back in the 90s. Back when static site generats were popular, before the latest slight resurgence.

To misquote Mitch Hedberg: People either love it or hate it, or they think it's ok.

Re: Ray Tracing in pure CMake

#112
post #5
post #2

Oh no... so far the most terrifying title I've seen in HN this year. By the way, it's impressive how they even managed to multithread this.

Someone might be working on an article even worse: list of things that raytracers haven't been written in (yet, regularly updated)

To pick from a recent HN thread: A raytracer has probably not been written yet using only printf. Who wants the glory?

Re: Ray Tracing in pure CMake

#113
post #46

Earlier quoted context omitted.

autotools. You may not like it, but it does work. If you like CMake more, that would be a good argument if CMake worked. But it doesn't. So in the choice between the thing that works, and the thing you may like more, please do go with the one that works. E.g. this comment I just wrote: https://news.ycombinator.com/item?id=25702345

if CMake works for LLVM, Qt, KDE, ReactOS, OpenCV and all the other projects in vcpkg there's some chance it's working for whatever your project is

Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS, with some dependencies in nonstandard locations, etc… etc…

It could. But it's an incredible coincidence that it's always cmake projects.

Generally on nonstandard installs the others (e.g. scons) won't even run, so portability of the conf is not relevant.

Re: Ray Tracing in pure CMake

#116
post #89
post #5

Earlier quoted context omitted.

Someone might be working on an article even worse: list of things that raytracers haven't been written in (yet, regularly updated)

When someone manages to write a raytracer in COBOL I will be truly impressed.

Nothing magic there. It's a full programming language.

Especially if output is in a text based image format like PPM.

Since I don't know COBOL at all, I'm not the one to do that.

Re: Ray Tracing in pure CMake

#117

Earlier quoted context omitted.

> Meson is more or less equivalent in the functionality it provides. but meson needs everything to be quoted which is frankly a gigantic PITA - like, look at that, there's more quoted stuff than anything else: https://mesonbuild.com/Generating-sources.html

I've not used it, but that wouldn't bother me too much. It's far preferable to a language like Bash where you're permitted to omit quotes, but consequently it's a minefield to write scripts that can robustly handle strings containing whitespace (e.g. arbitrary file paths). The Ada philosophy has it right: readability and correctness far outweigh writeability.

> The Ada philosophy has it right: readability and correctness far outweigh writeability.

Given the popular success of Ada I'm not sure I would call that "having it right" except in very specific circumstances

Re: Ray Tracing in pure CMake

#118

Earlier quoted context omitted.

if CMake works for LLVM, Qt, KDE, ReactOS, OpenCV and all the other projects in vcpkg there's some chance it's working for whatever your project is

Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS, with some dependencies in nonstandard locations, etc… etc… It could. But it's an incredible coincidence that it's always cmake projects. Generally on nonstandard installs the others (e.g. scons) won't even run, so portability of the conf is not relevan…

> Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS

what are you talking about ? take for instance kcachegrind, it builds with cmake and works on every architecture that debian supports (https://packages.debian.org/en/sid/devel/kcachegrind). I also never had issues with x32 when I used it, nor on freebsd. Can't say for openbsd but I'd be surprised it does not work there - this seems to point that other than a minor path issue things just work: https://www.sizeofvoid.org/posts/2020-03-29-how-to-build-qt5....

Re: Ray Tracing in pure CMake

#119

Earlier quoted context omitted.

I've not used it, but that wouldn't bother me too much. It's far preferable to a language like Bash where you're permitted to omit quotes, but consequently it's a minefield to write scripts that can robustly handle strings containing whitespace (e.g. arbitrary file paths). The Ada philosophy has it right: readability and correctness far outweigh writeability.

> The Ada philosophy has it right: readability and correctness far outweigh writeability. Given the popular success of Ada I'm not sure I would call that "having it right" except in very specific circumstances

There are various reasons Ada didn't take over the world, I'm not convinced that its emphasis on readability over writeability is one of them. Far more time is spent on maintaining code than on initial development, and anyway, typing speed isn't the bottleneck for writing new code.

Code review? You're in the business of reading code. Fixing bugs? You're in the business of reading code. Modifying/extending/porting an existing codebase? You're in the business of reading code.

If you're writing trivial single-use 'throwaway' code that needs no review, then readability doesn't much matter, but it's an important factor for just about all serious codebases.

Of course, there's also the question of whether Ada's specific syntax really succeeds in being more readable. It makes extensive use of English words in ways that are sometimes awkward and unnatural. I'm not a fan of its and then / or else short-circuit operators, for instance, and think they should just have gone with something like C's && / || operators. Neither syntax is self-explanatory to someone who doesn't know the language, but at least C's syntax doesn't counterintuitively collide with English.

Re: Ray Tracing in pure CMake

#120

CMake is by far the worst language I have ever worked in.

Oh thank god, this thread is making me feel much better about myself. I've been trying to integrate OpenCV's C++ library with my own C++ code (not involving Python), with the additional contrib modules (meaning I have to compile OpenCV myself), for multiple platforms, and I got stuck on CMake for so long it made me question if I was just a total idiot and should give up on programming forever.

Speaking as the author of the post, I completely agree! I got burned so many times by random shit that made no sense. Stringly typed languages are the absolute worst.
Post reply on HN