Earlier quoted context omitted.
Hackers works on things which are not trivial.so certainly not a hacker
Darn those non-hackers who don’t work on non-trivial things! :)
those are called software engineers :)
Ray Tracing in pure CMake
161–167 of 167 posts
Re: Ray Tracing in pure CMake
#162Earlier quoted context omitted.
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.
> It can happen with the autotools.
Yes. Again squared: project after project etcetera.
Re: Ray Tracing in pure CMake
#163> 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?
Thanks so much! I'll take a look at these when I get a chance
Re: Ray Tracing in pure CMake
#164Earlier 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…
Autotools and the configure script come from a history of distributing software purely as source code instead of binaries. From the early GNU days.
https://www.gnu.org/prep/standards/standards.html#Managing-R...
The intention was that software would be released as source code "tarballs" and contain a configure script, written in the lowest common denominator scripting language to configure that source code to compile on the users system. Additionally by distributing the configure script itself instead of configure.ac, users tend to need fewer dependencies that they don't already have.
It's _less_ applicable now that most users get pre-built binaries from package managers and it just feel pretty antiquated overall. But yeah the intention is that configure is platform agnostic and prepares your source code tree to build on the current platform. Whereas autoconf/autoreconf is intended as a tool for the developer to make writing "configure" a lot easier.
Re: Ray Tracing in pure CMake
#165> 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?
Thanks so much! I'll take a look at these when I get a chance
Thanks for merging all my PRs. :-)
Re: Ray Tracing in pure CMake
#166Can it run crysis?
Re: Ray Tracing in pure CMake
#167Earlier 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…
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)
What was the issue with QBS? The syntax looks clean and concise. Seems like the main issue is lack of traction.