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

141–150 of 167 posts

Re: Ray Tracing in pure CMake

#141

Post by rualca »

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…

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

Google "cmake --trace-expand"

Is that your main gripe with Cmake?

Re: Ray Tracing in pure CMake

#142

Post by knorker »

jcelerier wrote: post #118
knorker wrote: post #113

Earlier quoted context omitted.

Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS, with some dependencies in nonstandard locations, etc… etc… It could. But it's an incredible coincidence that it's always cmake projects. Generally on nonstandard installs the others (e.g. scons) won't even run, so portability of the conf is not relevan…

> Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS what are you talking about ? take for instance kcachegrind, it builds with cmake and works on every architecture that debian supports ( https://packages.debian.org/en/sid/devel/kcachegrind ). I also never had issues with x32 when I used it, nor on fre…

Again, project after project that doesn't work under those settings.

I'm not saying CMake itself doesn't work. Though I have run into both "CMake version is too old!" and "CMake version is too new!", which by its nature can't happen with autotools.

Re: Ray Tracing in pure CMake

#143

Post by knorker »

cycloptic wrote: post #101
knorker wrote: post #88

Earlier quoted context omitted.

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

I've built it too. That's not the point. It's the yak shaving of "I just want to compile this thing here" that turns into "what options do I need for building Python", and "how do I then get these third party Python modules with a custom install script to install into the correct Python path. And what exactly should I set PYTHONPATH and LD_LIBRARY_PATH to".

Keep in mind that I have to do all this just to build some C++ binary because someone decided to not use autotools.

Re: Ray Tracing in pure CMake

#144

Post by bluGill »

andi999 wrote: post #132
ahartmetz wrote: post #71

Earlier quoted context omitted.

The documentation is "complete" in the way that some manpages are - the biggest problem with it is the lack of best practices guidance. About books, I believe that good ones exist now. The official CMake book is not among the good ones - last time I checked, it was ridiculously outdated (and IMO not even very good at the time it was written). I have extracted some knowledge from the source code. It's more underdesign…

Which cmake book is good?

Professional cmake seems to be the one recommended now. The author updates it regularly.

Re: Ray Tracing in pure CMake

#145

Post by MaxBarraclough »

tn1 wrote: post #126
MaxBarraclough wrote: post #110

Earlier quoted context omitted.

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

> CMake has working FindXyz modules for most major libraries Unless you have that library installed anywhere that is not /usr/include Then you have to just hope and pray that there's some magic incantation that will make it find the right one (especially if your system-installed version is the wrong version and you'd really like to use the newer version you installed to $HOME)

Right, but it's always like this. If you're on Windows and you install Boost to C:\random\directory, it seems fair that CMake will require you to specify that directory manually.

The alternative is to have a global database, like the Windows registry or like pkg-config (which I have to admit I don't know much about). Perhaps CMake could have better support for pkg-config, I don't know.

Re: Ray Tracing in pure CMake

#146

Post by IshKebab »

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…

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

Re: Ray Tracing in pure CMake

#147

Post by IshKebab »

kevin_thibedeau wrote: post #49
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…

The syntax has improved slightly in recent releases with the target family of commands. You just have to know what legacy parts to avoid which is itself a burden. Still it beats digging into the bowels of autotools. I do fantasize about a new Cmake frontend implemented with Tcl scripting. That would be far more consistent and flexible and you can disable much of the language by default to minimize footbullets then al…

The target commands don't change the syntax at all. And your definition of "recently" is very loose! I've been doing CMake for 6 years and always used the target versions of commands.

Re: Ray Tracing in pure CMake

#148

Post by jcelerier »

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…

QBS was such an attempt to declarative building in C++ in a declarative way which looks sooo elegant on a first glance, and we all saw how well it did work out (it did not)

Re: Ray Tracing in pure CMake

#149

Post by rleigh »

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?

Autoconf requires GNU m4 at build time and POSIX sh at runtime. It also requires all the standard UNIX command-line tools you would run from the shell. Automake requires Perl at build time and Make (preferably GNU Make) at build time.

A stock Windows system doesn't have these tools. Cygwin and MinGW/MSYS provide these, but you're using stuff which is non-standard for the platform and which if you need to integrate with other libraries and tools, end up being incompatible.

If you want to use MSVC, the Autoconf/Automake support is poor. Generating output other than Makefiles is possible, but limited and quite the undertaking.

CMake supports all these other use cases out of the box. Which is why it gets used. It works on every platform, and with every compiler, build system and IDE of note.

Re: Ray Tracing in pure CMake

#150

Post by rleigh »

knorker wrote: post #142
jcelerier wrote: post #118

Earlier quoted context omitted.

> Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS what are you talking about ? take for instance kcachegrind, it builds with cmake and works on every architecture that debian supports ( https://packages.debian.org/en/sid/devel/kcachegrind ). I also never had issues with x32 when I used it, nor on fre…

Again, project after project that doesn't work under those settings. I'm not saying CMake itself doesn't work. Though I have run into both "CMake version is too old!" and "CMake version is too new!", which by its nature can't happen with autotools.

It can happen with the autotools.

The reason it hasn't been seen recently is that there has been no significant development of note for the past 15 years.

Even so, it's still common for the distributed config.sub and config.guess to be outdated. That's the price you pay for embedding stuff in each package, as opposed to requiring the build tool to be provided on the build system just like all the other tools.

Post reply on HN