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

91–100 of 167 posts

Re: Ray Tracing in pure CMake

#91

Post by knorker »

asddubs wrote: post #25
knorker wrote: post #19

Well well well, we finally found something CMake can actually do. Please, everyone, stop using CMake. It doesn't do its one job.

I'll agree CMake is pretty rough to get into, but what makes you say it doesn't do it's one job?

It doesn't produce portable projects. If all you wanted was Linux (or often "Ubuntu compatible") then why not just have a raw Makefile?

It doesn't log what it attempted, or why it failed.

It can't find out how to link binaries (always awesome to set up som execsnoop (because no logs, remember) only to see that it tries to link with "-llibfoo". In what world could that be correct?. And again it doesn't log how and why it chose that)

I could go on, but it's too much for a comment field.

Re: Ray Tracing in pure CMake

#92

Post by jcelerier »

ajconway wrote: post #53
MaxBarraclough wrote: post #21

Earlier quoted context omitted.

I agree that CMake is pretty awful, [0] but I'm not convinced that we'd be better off using its immature competitors, especially considering the fragmentation that would bring. [0] https://news.ycombinator.com/item?id=24203172

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…

> 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

Re: Ray Tracing in pure CMake

#93

Post by kortex »

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…

> Tho perhaps that's more of a failing of the OpenCV build script than Cmake itself?

That is exactly what that is. Cmake is extremely powerful, and it lets library authors make build configuration that is quite often too flexible. Combine that with no standardized package manager for c or c++ for decades, and much cmake evolution over that time, means you encounter many different ways to solve problems.

Opencv is up there for most complex cmake projects. Only behemoths like VTK, ITK, and ROS beat it in complexity of the build.

Also, don't beat yourself up too much. :)

Re: Ray Tracing in pure CMake

#94

Post by jcelerier »

knorker wrote: post #46
thebruce87m wrote: post #24

Earlier quoted context omitted.

If you’re going to tell us what not to use then at least suggest an alternative.

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

Re: Ray Tracing in pure CMake

#95

Post by knorker »

MaxBarraclough wrote: post #63
milanove wrote: post #56

Earlier quoted context omitted.

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…

I can't speak for MSVC support, but to me CMake fails all other bullet points. especially cross-platform package detection.

I haven't seen anything except autotools get this right.

Re: Ray Tracing in pure CMake

#96

Post by jcelerier »

knorker wrote: post #88
cycloptic wrote: post #66

Earlier quoted context omitted.

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

> Why? I don't see how it's different from requiring a user to install a compiler to build a particular language. The various build systems I've seen, including CMake, are portability projects in themselves. Yes, to build a C++ program you need a C++ compiler. But if it's using CMake then you need CMake. Oh, but you don't have that. Ok, now you have to install that. Oh, it requires Python X.Y (I'm not saying CMake do…

> But if it's using CMake then you need CMake. Oh, but you don't have that. Ok, now you have to install that.

you don't, CMake is able to bootstrap from nothing, it only requires a C++ compiler

> The whole thing about portability is that it should actually work even on systems you do not have access to. If all you need to support is Ubuntu 18.04 (or newer) and Windows, then why not just have a Makefile and a MSVC project file? That would be much easier than CMake or autotools.

having been in that exact place it's definitely not true

Re: Ray Tracing in pure CMake

#97

Post by kortex »

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

I'll tell you exactly how: trying to maintain cross platform ITK builds on tons of bespoke HPC clusters and academic workstations using the existing build tools became a nightmare.

Writing makefiles is extremely repetitive and tedious and error prone: precisely the kind of thing to automate. Not just makefiles mind you, cmake is designed to automate all sorts of build parameters.

Re: Ray Tracing in pure CMake

#98

Post by slavik81 »

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.

I used Waf before I tried CMake, and I found the latter much easier to understand. The CMake language is a mess, but the compilation model is simple.

Re: Ray Tracing in pure CMake

#99

Post by yudlejoza »

knorker wrote: post #83
yongjik wrote: post #55

Earlier quoted context omitted.

Everyone's experience is different, but that's very different from my memory of autotools - a Turing-complete macro processor which generates several thousand lines of pre-modern shell script with embedded C source codes. When anything goes wrong, it's pretty much impossible to match it to the original macro definition. Just so that one can hypothetically build the project in an ancient UNIX system which is so old th…

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 general-purpose language-agnostic macro processor I know of.

Re: Ray Tracing in pure CMake

#100

Post by flohofwoe »

knorker wrote: post #81
flohofwoe wrote: post #47

Earlier quoted context omitted.

I've never seen an autotools- or make-based project which builds out of the box on Windows in cmd.exe. Telling people to install cygwin just to build a project simply isn't viable when the default compiler toolchain on Windows is Visual Studio. Also it's not about building projects alone, cmake is also a project file generator for IDEs (in my case that was the actual reason why I switched to cmake from my own project…

Interesting. Why do they fail with autotools?

I don't know, I guess each project fails in a different way (my experience was mostly with libcurl before it came with cmake support), but IME projects which come with a Makefile or use autoconf don't care about non-UNIX-y operating systems, while (again: IME) a CMakeLists.txt file is often a sign that the project will also build on Windows with MSVC.
Post reply on HN