Ray Tracing in pure CMake • Hacker News Board

Re: Ray Tracing in pure CMake

#151

Post by rleigh » Sun, Jan 10, 2021, 12:07 PM UTC

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

The problem is that more often than not, the autotools don't work.

They were the go-to tools for the portability problems of the mid-late 90s and early 2000s. Unfortunately, since then they have stagnated, and they are now stuck solving portability problems very few of us have. But they don't do much for contemporary portability issues, while CMake most certainly does.

Most recent problems I've encountered are that Autotools failed to build properly with MinGW and Cygwin. CMake worked perfectly.

Since the decline and obsolescence of proprietary UNIX platforms, the main purpose of the Autotools has been effectively removed. Today, the Autotools work on Linux, BSDs and MacOS, but with pretty much everything else having been long obsoleted, the amount of testing on other UNIX platforms is both minimal and completely pointless. Few people care. They are dead. But, they still don't support the most popular platforms of today: Windows, Android and iOS. But CMake does.

Re: Ray Tracing in pure CMake

#152

Post by rleigh » Sun, Jan 10, 2021, 12:10 PM UTC

cycloptic wrote: post #43

IshKebab wrote: post #32

Earlier quoted context omitted.

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…

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

There was some work ongoing to move to Lua internally and gradually move over to it, but it's a huge task and I've not kept up on recent progress with this.

This would of course be a huge improvement, but there are many details to get right to support the old and new scripts in parallel to effect a smooth transition. But in the long term, this will resolve many complaints about CMake and really improve the semantics of the language and development and debugging of scripts.

Re: Ray Tracing in pure CMake

#153

Post by rleigh » Sun, Jan 10, 2021, 12:12 PM UTC

IshKebab wrote: post #146

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…

> How do you propose CMake supports all those build generators without doing this? I propose that it doesn't support build generators. It should do the build itself, like QBS did.

This would remove one of the key selling points of CMake, the fact that it is "glue" to permit development with any build tool or IDE of choice.

It's great that one person can be using Visual Studio on Windows while another uses CLion on MacOS and another uses Eclipse or Emacs on Linux, all working on the same codebase. It's a huge benefit for cross-platform tooling-independent development.

Re: Ray Tracing in pure CMake

#154

Post by rleigh » Sun, Jan 10, 2021, 12:21 PM UTC

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.

I don't understand the argument, it seems very circular.

Most software packages have a number of build dependencies as prerequisites for building, including a compiler, build tool like make/ninja, libraries and headers, other processors and tools like doxygen, sphinx, static analysis etc.

What makes the "build system generator" so unique in its requirements that this one tool must be embedded in the source package?

Nothing.

It's a convention adopted by the GNU Autotools initially for pragmatic reasons--the requirement that the end user install m4, perl, and a few other tools, and that in the early days the breakage between autoconf and automake minor versions was routine and really annoying. Today you can just run "autoreconf -fvi" for the same effect, and many packages have stopped distributing the generated scripts. Many distributions regenerate them as a matter of course, making the distributed copies redundant. Today, when we have fully-described and automatic installation of build-dependencies on most platforms, the need for embedding no longer exists.

I'm afraid that I don't buy your argument. Don't mistake historical conventions established for a single tool with a hard requirement. The requirement doesn't actually exist.

Re: Ray Tracing in pure CMake

#155

Post by rcxdude » Sun, Jan 10, 2021, 1:13 PM UTC

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.

It's very hard to avoid turing completeness, and it's normally not particularly valuable to avoid it unless you have some extremely strong requirement for formal reasoning about your code. I've not found that difficulty of understanding correlates well with turing completeness in practice (see regular expressions for an example of a non-turing complete system which are famously difficult to understand).

And in the case of a build system specifically, generally if you don't give some generally programmable interface to it then another wrapper layer will appear over it which does. Decisions in build systems are often enough complex enough to warrant a configuration language capable of expressing many different things. (This doesn't necessarily need to be an integral part of the build system: for example rust's package manager/build system, cargo, has a fairly simple non-turing complete configuration file but can run a build.rs program which can through a simple protocol of printing out values adjust many of the decisions cargo makes).

In fact, I'd say that CMake suffers most from not embracing that from the start. It's scripting language has clearly grown organically in a messy fashion from a configuration language, instead of being designed from the start with scripting in mind (at which point it may have just been a better idea to use an existing language, like lua, tcl, or python).

Re: Ray Tracing in pure CMake

#156

Post by kortex » Sun, Jan 10, 2021, 2:19 PM UTC

humanrebar wrote: post #109

kortex wrote: post #108

Earlier quoted context omitted.

What we could really use is some new declarative syntax that interoperates with existing cmake projects. There is already talk of such a system and even some implementations. I am sure many people have thought to themselves "This is so complicated! So much legacy cruft! I bet I could build a way cleaner c/c++ build system! " only to run into all of the complexity of cross platform c++. I highly doubt there will be a…

I like declarative approaches, but there's such a long tail of weird things to support. I'm skeptical something declarative can do the job on its own. Maybe some time after modules become available and then a known quantity.

The discussions mention this. Any such system would likely need to interoperate with existing building system, and serve as the leaf nodes wherever possible.

Re: Ray Tracing in pure CMake

#157

Post by TheRealSteel » Sun, Jan 10, 2021, 4:14 PM UTC

jcelerier wrote: post #87

TheRealSteel wrote: post #68

Earlier quoted context omitted.

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…

You may be correct. The way I understand it, those extra libs are only there in the desktop versions, not mobile, but it's definitely possible I misunderstood.

Still, even tho it was frustrating and felt like a waste of time, learning to compile a big project like OpenCV taught me alot, and all or part of that will probably be useful in the future anyway :) even as a dot point on a resumé

It improved my shell scripting skills, and helped me understand how C++ links, and what library files actually contain etcetera

Whether cmake is good or bad, and whether it was necessary for my project or not, now I have successfully used Cmake to compile a big library!

I have to statically link it anyway, so compiling OpenCV separately and manually allows me to cut it down and make build changes etc that might be useful, as well as forces me to look at how it's structured and understand it better.

Thanks for your help!

Re: Ray Tracing in pure CMake

#158

Post by TheRealSteel » Sun, Jan 10, 2021, 4:55 PM UTC

seabird wrote: post #79

TheRealSteel wrote: post #68

Earlier quoted context omitted.

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'!

Thanks!

To be honest I think alot of my frustration was with the OpenCV build scripts rather than Cmake itself, but I don't love Cmake either.

Re: Ray Tracing in pure CMake

#159

Post by s_gourichon » Sun, Jan 10, 2021, 11:41 PM UTC

> Conclusion

> If you made it this far, thanks for reading! Feel free to create issues, send pull requests or star the code on GitHub.

Done, fixed 3 bugs there https://github.com/64/cmake-raytracer/pull/4 https://github.com/64/cmake-raytracer/pull/5 https://github.com/64/cmake-raytracer/pull/6 . Do I deserve a medal? A punishment for feeding an abomination?

Re: Ray Tracing in pure CMake

#160

Post by nrdvana » Mon, Jan 11, 2021, 12:43 AM UTC

delta64 wrote: post #133

nrdvana wrote: post #130

Earlier quoted context omitted.

Btw, one of the things I came up with in bash was an “object oriented” pattern (antipattern?) where a “constructor” function would declare variables for “attributes” and functions for “methods”, like for example declaring an object named Vector1 whose fields are Vector1_x Vector1_y Vector1_z and methods like Vector1_Normalize and Vector1_SetMagnitude. The functions would be eval’d for each instance of the object duri…

It sounds like it should be possible (CMake also has eval), but the lack of OOP isn't so much a problem for what I needed. Packing and unpacking the vectors was more annoying. I can live without OOP, I've written enough C to get used to it haha.

Actually, thinking back, the primary reason I did that was that bash can’t dereference a variable by its name stored in another variable without an eval, and calling eval on each access of the variable was slow. By eval-ing the whole method ahead of time, I could access all the object attributes at runtime without any further evals. It looks like cmake has a getter/setter function that takes a name, so that wouldn’t be a problem here.