News for hackers. Stuff that matters.

A comment on Ray Tracing in pure CMake. Parent comment

Re:Ray Tracing in pure CMake by kortex on Saturday January 09, 2021 @05:14PM (#25705464)
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...

[ Parent | on HN ]
Re:Ray Tracing in pure CMake by humanrebar on Saturday January 09, 2021 @05:21PM (#25705549)
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.

[ Parent | on HN ]
Re:Ray Tracing in pure CMake by kortex on Sunday January 10, 2021 @09:19AM (#25714817)
The discussions mention this. Any such system would likely need to interoperate with existing building system, and serve as the leaf nodes wherever possible.
[ Parent | on HN ]
Re:Ray Tracing in pure CMake by jcelerier on Sunday January 10, 2021 @06:58AM (#25713822)
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)
[ Parent | on HN ]
Re:Ray Tracing in pure CMake by kortex on Thursday January 14, 2021 @03:46PM (#25782240)
What was the issue with QBS? The syntax looks clean and concise. Seems like the main issue is lack of traction.
[ Parent | on HN ]