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

81–90 of 167 posts

Re: Ray Tracing in pure CMake

#81

Post by knorker »

flohofwoe wrote: post #47
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'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?

Re: Ray Tracing in pure CMake

#82

Post by fbkr »

knorker wrote: post #45
flohofwoe wrote: post #33

Earlier quoted context omitted.

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.

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…

Could you explain how cmake stuff isn't portable or broken between different flavors of Unix? I comfortably maintain CMake builds that work on linux (with centos, ubuntu and arch), macos and windows without much trouble.

If you mean cmake versions, I'm not sure what you expect, should cmake just freeze in time and stop adding features so someone gets to use cmake from 5 years ago?

Also, the bit about autotools on windows is silly. If it can't build native windows stuff, it's not at all viable for windows.

I also dislike cmake (particularly dependency management) and wish for something better, but I think our criticisms should be well-founded.

Re: Ray Tracing in pure CMake

#83

Post by knorker »

yongjik wrote: post #55
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…

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 compiled scripts. Would you not look at logfiles and stderr output before you start looking at assembly?

CMake doesn't. The logs are completely useless, even when I get a CMake expert to come and agree, yes that's useless.

With autotools you can see that it failed to build because it couldn't find library foo when building with "gcc blah blah blah", and you go "well yeah, you need -L/opt/foo/lib", so you just add that. (or pkg-config equiv).

CMake, on the other hand, seems to force you to look at CMake "source code" (CMakeLists.txt), which is a horrible mess. I'm not saying autotools isn't (yay, m4 :-( ), but the point is you don't have to, because it actually logs what it does.

So this is one of the many many reasons CMake sucks.

Re: Ray Tracing in pure CMake

#84

Post by kortex »

knorker wrote: post #45
flohofwoe wrote: post #33

Earlier quoted context omitted.

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.

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…

> But even if not, CMake stuff as a rule is not even portable between different flavors of Unix,

Not sure what your experience has been but I've had zero problems with cmake portability on nixes.

Raw makefiles are so much worse from a maintainability point of view.

I find it kinda fascinating to be honest. Two devs come to totally opposite conclusions.

Also to get more logging try this: https://stackoverflow.com/a/22803821/3988037

Re: Ray Tracing in pure CMake

#85

Post by gumby »

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 of CMake as a coin with two faces: on one side is a cool engine that manages dependencies and can somehow wrangle Make/xcodebuild/ninja et al. On the other side is a dreadful interface (presumably due to legacy constraints) that you have to gingerly manipulate in the hope that it will cause the proper state changes on the other side so that it can generate the result you want...when I don't actually know what the internals of say Xcodebuild are.

It's sort of like using Italian to correspond with someone when you know Latin but not Italian.

If the code base really looks like that it might be interesting to implement a different front end. Even XML would be better.

On the other hand I couldn't imagine working without it and would be happy if it supported more languages (I only use it with C and C++).

Re: Ray Tracing in pure CMake

#86

Post by knorker »

linkdd wrote: post #77
admax88q wrote: post #62

Earlier quoted context omitted.

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

I would say that best practice is to NOT commit the generated files, but DO include them in release tarballs. Because release tarballs are exactly what need to be portable to all your users.

Re: Ray Tracing in pure CMake

#87

Post by jcelerier »

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…

> Once I sat down and read the Cmake basics, yes, it was easy enough to get OpenCV working with basically 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.

If this worked on desktop, I would assume this to be a bug in the OpenCV cmake files, there's no reason for aruco not to be in OpenCV_libs if my understanding of the OpenCV build system is correct (but then I did not really have to fight it)

Re: Ray Tracing in pure CMake

#88

Post by knorker »

cycloptic wrote: post #66
knorker wrote: post #59

Earlier quoted context omitted.

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…

> 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 does, but I've seen others that do, and CMake has other similar things)? Oh, this system doesn't have that. So now I need to build Python from source. Does Python have any dependencies, perhaps? (or worse, you have to use backports, which pull in 1000 dependencies so that now you have a frankensystem)

If you've ever been at the point where two steps down the dependency chain you have to build something as fundamental as Python, then you probably know that this is not a fun experience. And in fact you may run out of disk space, several gigs of source and object code later. (not every system is a 100TB server)

The whole thing about portability is that it should actually work even on systems the original developer does 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.

Oh, and I've also been hit by dependencies of the build system being too NEW. E.g. CMakeList.txt using features removed in newer versions.

And that's how autotools is different. The ONLY dependency is a POSIX shell. Do you have that? Then you can build.

The number of times I've seen CMake try to link with "-llibfoo" (it's "-lfoo") or be entirely confused about how I'm not running the exact same system the developer is, I can't even count. (e.g. failing to build because "this is not an amd64 system"… uh, yes it is, with zero logs about why it thinks that)

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

Well that just means CMake has nothing at all going for it, if they are as portable.

Re: Ray Tracing in pure CMake

#89

Post by acka »

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)

When someone manages to write a raytracer in COBOL I will be truly impressed.

Re: Ray Tracing in pure CMake

#90

Post by jcelerier »

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…

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

... so does CMake ? you get log of the errors in CMakeFiles/CMakeError.log, and you can trace what happens line by line in a very verbose way with cmake --trace (or cmake --trace-expand if you want variables to be expanded)

Post reply on HN