←back to thread

101 points NormalExisting | 10 comments | | HN request time: 0.649s | source | bottom

Been making this rasterizer engine in C++ for the past few months, now also adding ray-tracing functionality to the system.

Simply load a model or generate a mesh, add some lights, and render.

Show context
DrFalkyn ◴[] No.43343281[source]
If portability is a goal you might want to use CMake and Docker.
replies(2): >>43343309 #>>43344650 #
1. johnnyjeans ◴[] No.43343309[source]
make is more portable than cmake. docker has zero value add from what I saw in the repo.
replies(3): >>43343564 #>>43343587 #>>43344017 #
2. DrFalkyn ◴[] No.43343564[source]
How about fixing the version of the compiler and the dependencies so you don’t get build errors ?

Yes it only works for Linux. But these days it’s pretty easy to get a Foam with WSL on Windows and Docker for desktop

Sticking with a Makefile is going get increasingly unwieldy for a large project

3. Shorel ◴[] No.43343587[source]
Definitely not true in my experience.

Want to describe your issues with CMake?

Maybe the community can help you.

replies(2): >>43345291 #>>43345651 #
4. psyclobe ◴[] No.43344017[source]
Make is quite a bit more headache these days to consume then make (in modern code bases anyway).
replies(1): >>43345532 #
5. ◴[] No.43345291[source]
6. johnnyjeans ◴[] No.43345532[source]
I'm not actually a fan of make, I think mk is a much better language, but everything is relative. I still prefer make over any meta-build system or garbage like boost jam. In my experience the problem of modern codebases is that they're structured like crap in the first place. Too complicated and for very little real reason. OP's codebase is actually trivial, so the problem doesn't really exist. It would be trivial to adapt it to use msvc, but if you have make on windows, chances are you already have gcc so there's not much point unless you REALLY want to use microsoft's compiler.
7. johnnyjeans ◴[] No.43345651[source]
It's inherently less portable as it relies on C++ and the cmake language is rather complicated, and thus making it harder to implement. Make and more preferable mk, are reliant on C, and are simpler languages making them easy to implement. It's simple portability calculus.
replies(1): >>43351324 #
8. menaerus ◴[] No.43351324{3}[source]
Portability-wise this was perhaps the case ~20 years ago but today I am not aware of any platform that doesn't have a decent C++ compiler so I don't think what you're saying is generally true.

I also don't agree on the second point - I don't see what makes the CMake "harder to implement" than make/mk. It's already implemented and all you need is a compiler, which we have plenty of.

replies(1): >>43363341 #
9. johnnyjeans ◴[] No.43363341{4}[source]
> I am not aware of any platform that doesn't have a decent C++ compiler

Plan 9

> I don't see what makes the CMake "harder to implement" than make/mk

If you can't use the existing codebase, then you have to implement cmake from scratch, which is orders of magnitude more difficult than implementing a mk interpreter.

replies(1): >>43370843 #
10. menaerus ◴[] No.43370843{5}[source]
I hope you're aware how loose of an argument this is.

> Plan 9 is a research operating system, and exists to answer questions about ideas in OS design. As such, the Plan 9 experience is in essence an exploration of the interesting ideas it puts forth. Most of the ideas are small.

> ...

> Plan 9 failed, in a sense, because Unix was simply too big and too entrenched by the time Plan 9 came around. It was doomed by its predecessor. Nevertheless, its design ideas and implementation resonate deeply with me, and have provided an endless supply of inspiration for my own work. I think that everyone owes it to themselves to spend a few weeks messing around with and learning about Plan 9. The dream is kept alive by 9front, which is the most actively maintained fork of Plan 9 available today. Install it on your ThinkPad and mess around.

[0] https://drewdevault.com/2022/11/12/In-praise-of-Plan-9.html