Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ray Tracing in pure CMake

64.github.io

Post reply on HN
Print view View original

71–80 of 167 posts

Re: Ray Tracing in pure CMake

#71

Post by ahartmetz »

andi999 wrote: post #34
bluGill wrote: post #27

Earlier quoted context omitted.

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)

The documentation is "complete" in the way that some manpages are - the biggest problem with it is the lack of best practices guidance. About books, I believe that good ones exist now. The official CMake book is not among the good ones - last time I checked, it was ridiculously outdated (and IMO not even very good at the time it was written).

I have extracted some knowledge from the source code. It's more underdesigned than overdesigned and I think that's the better side to err on. Kinda awkward but you can figure it out.

Re: Ray Tracing in pure CMake

#72

Post by cycloptic »

kevin_thibedeau wrote: post #49
cycloptic wrote: post #43

Earlier quoted context omitted.

>The separation of the configure step from the build step is needlessly confusing and makes some things impossible. I'm confused. How do you propose CMake supports all those build generators without doing this? (PS. I really don't think the syntax is that bad, aside that it is jarring for C programmers, most complaints are overblown and you get used to it once you learn the rules. It might be interesting if someone m…

The syntax has improved slightly in recent releases with the target family of commands. You just have to know what legacy parts to avoid which is itself a burden. Still it beats digging into the bowels of autotools. I do fantasize about a new Cmake frontend implemented with Tcl scripting. That would be far more consistent and flexible and you can disable much of the language by default to minimize footbullets then al…

I guess I just don't see where there are footguns and unsafety here. Build scripts are intended to operate on a known, fixed set of inputs.

Re: Ray Tracing in pure CMake

#73

Post by kortex »

hzhou321 wrote: post #67

I think this is a demonstration why CMake is bad. Unless it's a general purpose programming language, being Turing complete should always be listed in the "Con" side. It literally means the effort needed to understand its complexity can be unbounded.

Cmake isn't the problem, it's a solution to the complexity of building huge c and/or c++ projects such as VTK such that you can run on many different OSes, arches and platforms, with hundreds of different build options.

That is just what you get with legacy build systems.

Disclosure: I work at Kitware.

Re: Ray Tracing in pure CMake

#74

Post by vlovich123 »

kortex wrote: post #73
hzhou321 wrote: post #67

I think this is a demonstration why CMake is bad. Unless it's a general purpose programming language, being Turing complete should always be listed in the "Con" side. It literally means the effort needed to understand its complexity can be unbounded.

Cmake isn't the problem, it's a solution to the complexity of building huge c and/or c++ projects such as VTK such that you can run on many different OSes, arches and platforms, with hundreds of different build options. That is just what you get with legacy build systems. Disclosure: I work at Kitware.

I think Skylark (the language for Buck/Basel) represents an interesting compromise here that I like better, even though in the past I was a huge Cmake advocate.

The majority of rules are declarative and easily understood. Python (or at least a dialect extremely close to Python) is how you extend and write new rules. The two live in very different files (declarative rules are in BUCK/BUILD files, .bzl files contain the imperative definitions of rules, and various other conventions control how you deal with platforms (ie select rules).

Re: Ray Tracing in pure CMake

#75

Post by vlovich123 »

linkdd wrote: post #48
knorker wrote: post #45

Earlier quoted context omitted.

I keep running into CMake based things not being portable, and being broken. And pretty much every single time cmake fails, it does not have ANY log AT ALL of what it did, and why it thinks libfoo is not there. Take autotools. You get EXACTLY what it did, and you see why it failed. With CMake it just goes "you don't have X installed". But I do. It's right there. CMake refuses to say under what cmdline or whatever it…

I never managed to get CMake to work out-of-the box on Windows. I always end up vendoring the dependencies, because it's too tedious to find the correct installed libraries in a cross-platform way. autotools are great, but at the same time it's a monstrosity, and easy to misuse (you should never commit the configure script, because it's the autotools that are supposed to generate it according to the platform it's run…

You probably may want to use Bazel. Buck’s Windows support at Facebook was fine (most all the PC oculus stuff is built with Buck) but I don’t know what state the OSS version is in (maybe technically has support but the internal pieces that make it work well don’t have OSS equivalents that are decoupled from other FB-internal things).

Re: Ray Tracing in pure CMake

#77

Post by linkdd »

admax88q wrote: post #62
linkdd wrote: post #48

Earlier quoted context omitted.

I never managed to get CMake to work out-of-the box on Windows. I always end up vendoring the dependencies, because it's too tedious to find the correct installed libraries in a cross-platform way. autotools are great, but at the same time it's a monstrosity, and easy to misuse (you should never commit the configure script, because it's the autotools that are supposed to generate it according to the platform it's run…

> autotools are great, but at the same time it's a monstrosity, and easy to misuse (you should never commit the configure script, because it's the autotools that are supposed to generate it according to the platform it's running on). The configure script is not generated according to the platform it is running on. The whole reason tbe configure script is such a monstrosity is because its supposed to be portable, its…

From my experience, `autoreconf -i` is responsible for generating the configure script from a configure.ac file, so I assumed some platform-specific logic was happening.

I always wrapped it up in a autogen.sh script that I did commit. Also, end users generally prefer prebuilt binaries, if one wants to compile the software themselves, I expect him to have autotools installed, and mention it as a requirement in the README.

Re: Ray Tracing in pure CMake

#78

Post by appleflaxen »

bluGill wrote: post #27
skohan wrote: post #20

Earlier 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.

which competitors?

any thoughts on why are build tools so hard to get right?

Re: Ray Tracing in pure CMake

#79

Post by seabird »

TheRealSteel wrote: post #68
jcelerier wrote: post #40

Earlier quoted context omitted.

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…

Thanks for your reply. Will this include the contrib modules even for Android? And iOS? Once I sat down and read the Cmake basics, yes, it was easy enough to get OpenCV working with basicallly the code you posted, except I couldn't find a way to include the contrib modules in an Android version, it would always complain Aruco wasn't there. Until I went and compiled OpenCV myself, and that was the part that was a mass…

Humility is good, but it's important to acknowledge that CMake very often feels awful. I consider myself a competent developer and it's still pulling teeth trying to get what I want out of it.

Some things will get easier with time, and a lot of other things are going to suck shit forever. Keep on truckin'!

Re: Ray Tracing in pure CMake

#80

Post by gumby »

chubot wrote: post #76

This is cool, someone should port this to bash, which also only supports integers. Then I can use it as a benchmark for https://www.oilshell.org :) Also bash can do the multicore part very easily with processes, like cmake.

> This is cool, someone should port this to bash, which also only supports integers.

With a little bitfield support (you could always call out to dc but you can do boolean arithmetic directly in bash) you can simply implement IEEE 754 in bash.

Post reply on HN