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

101–110 of 167 posts

Re: Ray Tracing in pure CMake

#101

Post by cycloptic »

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…

I've built cpython, it's about as inconvenient as building the compiler and runtime for any other major language. What OS ships binaries for gcc/clang but not python? I can't say I've seen any Linux distros that don't have it.

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

Sorry, just to be clear, Visual Studio does not have built in support for autotools. (Unless they added it recently and I wasn't aware) But, there are a number of other less convenient ways to get that to work on Windows.

Re: Ray Tracing in pure CMake

#102

Post by kortex »

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've voted this post down for this in particular. It is truly an absurd criticism, especially when you refute it yourself when you admit bash on Windows is a relatively new phenomenon (and I still struggle with bash env on Windows). If you use a build system, you need a build system installed, full stop. Cmake is pretty easy to bootstrap on a new host with minimal assumptions. Literally just `./bootstrap; make` on basically any 'nix.

Cmake is designed to run truly anywhere, with many backing generators, not just make. It doesn't even assume a posix shell iirc.

Sounds like many of your complaints are with the library authors not writing with portability in mind.

Re: Ray Tracing in pure CMake

#103

Post by pjmlp »

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 bet you never tried to write large scale Makefiles across several OSes, even POSIX ones.

Re: Ray Tracing in pure CMake

#105

Post by tdiff »

So far the funniest bug with cmake I've fixed was when we were accidentally setting a variable with name '0' to a value '1'. Later on, in other module, we were checking if some other variable was equal to '0' which was interpreted by cmake as a variable reference so the actual check was with '1'.

Re: Ray Tracing in pure CMake

#106

Post by pjmlp »

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…

Windows is not the only non-UNIX OS around.

Re: Ray Tracing in pure CMake

#107

Post by MaxBarraclough »

jcelerier wrote: post #92
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…

> 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

I've not used it, but that wouldn't bother me too much. It's far preferable to a language like Bash where you're permitted to omit quotes, but consequently it's a minefield to write scripts that can robustly handle strings containing whitespace (e.g. arbitrary file paths). The Ada philosophy has it right: readability and correctness far outweigh writeability.

Re: Ray Tracing in pure CMake

#108

Post by kortex »

MaxBarraclough wrote: post #21
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 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

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 cargo for c/c++, because it simply isn't rust.

https://gitlab.kitware.com/cmake/cmake/-/issues/19891

https://gist.github.com/stryku/4c69aa510711c9da6705fa4df4545...

Re: Ray Tracing in pure CMake

#109

Post by humanrebar »

kortex wrote: post #108
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

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.

Re: Ray Tracing in pure CMake

#110

Post by MaxBarraclough »

knorker wrote: post #95
MaxBarraclough wrote: post #63

Earlier quoted context omitted.

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.

> especially cross-platform package detection

I disagree here. CMake has working FindXyz modules for most major libraries. To write one of those modules is an exercise in soul-destroying tedium, but there's a pretty impressive body of existing modules out there, many of them officially bundled with CMake.

When used correctly, both CMake and Autotools are capable of robust package-detection.

Regarding point 1: CMake works pretty well on Unix, but it's a pity there's a runtime dependency on the CMake package. Autotools is much better in that particular regard: just about any Unix system can run a configure script, as it's just a plain old shell script.

CMake certainly falls short on the final 2 points, as I rambled about at https://news.ycombinator.com/item?id=24203172

It's too late for me to edit my earlier comment, but here's another alternative to CMake for the list: Bazel.

Post reply on HN