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

61–70 of 167 posts

Re: Ray Tracing in pure CMake

#61

Post by jpm48 »

jcelerier wrote: post #40
TheRealSteel wrote: post #30

Earlier quoted context omitted.

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…

plus 1 for this, I have been using CMake with my students for a year (moving from qmake) and this in conjunction with vcpkg to install stuff has been a breeze. This book is great too https://crascit.com/professional-cmake/

Re: Ray Tracing in pure CMake

#62

Post by admax88q »

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…

> 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 written in the lowest common denominator of shell. You are supposed to distribute it. Its also fine to check in if you want end users building directly from VC rather than from tarballs. Just dont modify it by hand.

Re: Ray Tracing in pure CMake

#63

Post by MaxBarraclough »

milanove wrote: post #56
ajconway wrote: post #53

Earlier quoted context omitted.

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…

Waf is another interesting build system I've seen used in production. It's config is done with Python scripts, which is cool.

There's also Premake, [0][1] Buildout, Ninja, SCons, and no doubt there are others. qmake was recently deprecated.

It would take a lot to persuade me to move away from CMake and to use something 'non-standard' that few developers are familiar with:

* Excellent support for command-line builds on Unix

* Excellent support for Visual Studio

* Excellent cross-platform package-detection. (Acid test: Can it detect and link against OpenCL without me having to write my own cross-platform OpenCL-detection script?)

* Excellent documentation, including clear and consistent best practices and design patterns

* A sensible language, whether a scripting language or a declarative language. Must follow the principle of least astonishment and be relatively free of foot-guns. (CMake fails tragically on both counts.)

[0] https://premake.github.io/

[1] https://en.wikipedia.org/wiki/Premake

Re: Ray Tracing in pure CMake

#64

Post by master_yoda_1 »

prox wrote: post #39
dev_tty01 wrote: post #35

Earlier quoted context omitted.

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! :)

Hackers works on things which are not trivial.so certainly not a hacker

Re: Ray Tracing in pure CMake

#65

Post by aidenn0 »

discardable_dan wrote: post #58
fouronnes3 wrote: post #28

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

Agreed. I will never understand how a group looked at overly-complex Makefiles, determined it was hard to write complex build scripts, and concluded: "I should write a Makefile meta-language that can generate these." That would be like looking at a complex Java codebase and concluding that the best solution to simplify it would be to write a Java meta-language for generating your classes...

If you only ever generate makefiles with cmake, then you probably don't need cmake.

Re: Ray Tracing in pure CMake

#66

Post by cycloptic »

knorker wrote: post #59
discardable_dan wrote: post #57

Earlier quoted context omitted.

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-c…

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…

>Any portable build system, that already requires EVERY user to have that build system installed, is DoA for being a viable portable build system.

Why? I don't see how it's different from requiring a user to install a compiler to build a particular language. Operating systems don't have every compiler installed by default. To fulfill your requirements, one would have to re-implement every build system and compiler in POSIX shell. Honestly the "better way" that I see a lot of projects going with is to just support multiple options for build systems, because there is no one perfect solution that is going to work on all platforms.

The elephant in the room here is windows, and at this current point in time, CMake is about as portable there as autotools because Visual Studio has built in support for it.

Re: Ray Tracing in pure CMake

#67

Post by hzhou321 »

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.

Re: Ray Tracing in pure CMake

#68

Post by TheRealSteel »

jcelerier wrote: post #40
TheRealSteel wrote: post #30

Earlier quoted context omitted.

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…

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 massive pain in my ass - CMake failing to include architecture information in the library files unless you specify it on the command line before running Cmake GUI, even tho it is an option in the GUI. Tho perhaps that's more of a failing of the OpenCV build script than Cmake itself?

I did just recompile OpenCV myself, so I did get there in the end and it's all working now, but I'm sure I'll be tweaking all parts of this project for months to come so if there's an easier/proper way, I'm happy to learn.

It also needs to be statically linked.

Note: I'm not a real programmer, I don't know enough to have even been able to get an entry level job in the industry yet, I'm an idiot that doesn't belong on this website. I'm just trying to learn as I go.

Re: Ray Tracing in pure CMake

#69

Post by kortex »

usrusr wrote: post #5
logimame wrote: 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)

Well, if you can store data in icmp packets, I bet you can do math, too.

https://github.com/yarrick/pingfs

Re: Ray Tracing in pure CMake

#70

Post by jmagoon »

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.

My least favorite part is how completely impossible it is to discover all the implicit variables set by other cmake files, and there's no common convention, so some libraries are like ${ZLIB_INCLUDE_DIR} and some are #{zLib_INCLUDE_DIRS} and you have to just manually try a bunch of combinations to finally find what works because the scripts themselves use weird string based metaprogramming to build the variables themselves.
Post reply on HN