This is an ode to how much you can do with the four arithmetic operations and not much more
Ray Tracing in pure CMake
31–40 of 167 posts
Re: Ray Tracing in pure CMake
#32Well well well, we finally found something CMake can actually do. Please, everyone, stop using CMake. It doesn't do its one job.
What's wrong with CMake?
The language is extremely error prone. It's like they looked at Bash and thought "hmm, too safe".
Everything is a string, even lists are just semicolon-separated lists. The argument expansions rules for calling functions are literally impossible to remember. All variables are implicitly defined as empty strings. Typos silently break things. `if` is completely broken. The separation of the configure step from the build step is needlessly confusing and makes some things impossible. This is just scratching the surface.
It does have a couple of redeeming qualities: they have a pretty great versioning mechanism which allows them to make breaking changes. Though inexplicably they haven't used it to fix any fundamental flaws, only little tweaks. And most importantly it has been around for ages so loads of the many many weird C++ compilation knobs have been solved.
Re: Ray Tracing in pure CMake
#33Well well well, we finally found something CMake can actually do. Please, everyone, stop using CMake. It doesn't do its one job.
The scripting language is bad, most cmake scripts are much more complex than they should be, but cmake does a lot of things under the hood that make multi- and cross-platform development easier (for example: being able to build with the Visual Studio compiler without running in the "Visual Studio Developer Command Prompt").
A lot of fancy new build tools don't even have proper Windows support.
Re: Ray Tracing in pure CMake
#34Earlier quoted context omitted.
What's wrong with CMake?
The syntax is weird and inconsistent. Built ins are case insensitive, but user defined functions are sensitive. No way to return values from functions, except by jumping to the scope of the caller and changing its variables unexpectedly. (Better hope you know what the caller does) That isn't a complete list . Despite the above cmake is your best choice of build system for C. Though some competitors could overtake it.
On top of that I found the documentation and the book terrible. I thought it might be easier to understand what it does by reading the source code (didn't try yet)
Re: Ray Tracing in pure CMake
#35Oh 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)
Next thing you know someone will suggest HN with hierarchy for repeated and unrelenting topics. Linux ports on home appliances, ray tracing, vi vs. emacs, launchd vs systemd, walled gardens, .... Oh no, say it isn't so!
Re: Ray Tracing in pure CMake
#36Well well well, we finally found something CMake can actually do. Please, everyone, stop using CMake. It doesn't do its one job.
I absolutely despise cmake. But autotools is even worse, so it’s what I end up using. I haven’t found another approach which handles my needs.
What are the needs
Re: Ray Tracing in pure CMake
#37Earlier quoted context omitted.
What's wrong with CMake?
The language is extremely error prone. It's like they looked at Bash and thought "hmm, too safe". Everything is a string, even lists are just semicolon-separated lists. The argument expansions rules for calling functions are literally impossible to remember. All variables are implicitly defined as empty strings. Typos silently break things. `if` is completely broken. The separation of the configure step from the buil…
> It's like they looked at Bash and thought "hmm, too safe".
One of my favorite comments in a while. :-)
Re: Ray Tracing in pure CMake
#38I remember writing a ray tracing in 1994 in Turbo Pascal 7.0 running on 286 under DOS 4.0 at the time. I did it with floating numbers, pure mathematical implementation. When it came to usability was something like 1 frame every 30 seconds for resolution of 640x480 with 256 colors only. The problem with ray tracing isn't writing one, the problem is its usability, to get the most realistic AND fast enough. Mine was ver…
640x480 256 colours on a 286? With only 30 seconds for an image, even though it doesn't have a floating point unit? Sorry for being a doubting Thomas, but that seems very implausible (having spent my life writing ray tracers).
Re: Ray Tracing in pure CMake
#39Earlier 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)
Next thing you know someone will suggest HN with hierarchy for repeated and unrelenting topics. Linux ports on home appliances, ray tracing, vi vs. emacs, launchd vs systemd, walled gardens, .... Oh no, say it isn't so!
Those darn Hackers on hackernews! :)
Re: Ray Tracing in pure CMake
#40CMake 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.
to give another data point: I was given a project a couple weeks ago that was using visual studio solutions and opencv + contrib modules - I fighted 3 hours with making the .vcxprojs work on my machine before porting the whole shit to cmake in 15 minutes.
Using OpenCV was just a matter of
find_package(OpenCV 3.3.1 REQUIRED)
target_include_directories(theApp PUBLIC ${OpenCV_INCLUDE_DIRS})
target_link_libraries(theApp PUBLIC ${OpenCV_LIBS})